Finding XSS Through HTML Injection — Without Fuzzing Tools | by Windasunny | in InfoSec Write-ups - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original Finding XSS Through HTML Injection — Without Fuzzing Tools Note: All sensitive information has been redacted Windasunny Follow InfoSec Write-ups · ~2 min read · March 27, 2026 (Updated: March 27, 2026) · Free: Yes Note: All sensitive information has been redacted When hunting for XSS, most people immediately reach for fuzzing tools. But sometimes, slowing down and simply observing how an application behaves can uncover just as much — if not more. Where did the HTML Injection come from? While testing the application, I wasn't actively fuzzing inputs at that time. Instead, I was following normal business logic, trying to understand how the system works and whether any logical flaws existed. During this process, I noticed something interesting while inspecting the page source. This immediately stood out. Why? Because the application is built on a modern framework where routing is handled cleanly — no .php files are exposed anywhere else. Every page follows a consistent route-based structure. Yet here was a direct reference to a .php endpoint. That inconsistency is often a signal worth investigating. — Testing for Injection Naturally, the next step was to test whether the parameter was injectable. I started with a harmless payload:

Hello

The result? It rendered successfully — not escaped, not sanitized. That confirmed HTML injection. Next, I tried a classic XSS payload: Blocked. At first glance, it looked like a WAF was doing its job. But the filtering behavior suggested something superficial — likely keyword-based blocking. So I adjusted the payload slightly: