Before you start: This lesson builds directly on SQL injection (Server-Side Injection category) and XSS (Cross-Site Scripting & Client-Side category) — the examples throughout assume you know what these attacks do. You also need a working Burp Suite setup from the Recon, Scanning & Traffic Tools category.
Real targets rarely accept a textbook payload verbatim. Somewhere between your input and the vulnerable code there is usually a guard: a hand-rolled input filter in the application, or a web-application firewall (WAF) in front of it, rejecting anything that looks like an attack. Fire <script>alert(1)</script> at a filtered field, watch it get blocked, and it is tempting to conclude "not vulnerable" — the single most common false negative in web testing. The flaw is usually still there. The payload just needs to be dressed differently so it slips past the guard but still detonates at the sink (the vulnerable server-side code that actually interprets the input, such as a SQL engine or an HTML renderer).
This lesson teaches the two-step discipline that separates a tester from a scanner:
- Detect that a filter or WAF is present, and learn exactly what it blocks.
- Bypass it with encoding and obfuscation — keep the meaning, change the bytes.
Why guards leak
Most filters and WAF rules are, at heart, a blocklist: a list of known-bad strings to reject. But the set of strings that mean the same thing to the eventual interpreter is effectively infinite — <ScRiPt>, %3Cscript%3E, <script>, <scr<script>ipt> all collapse back to <script> somewhere downstream. Every encoding, case, comment, and whitespace variant is one more string the blocklist author would have had to predict. That structural gap is what you will exploit.
In this lesson you will
- See where input filters and WAFs sit, and the difference between signature and anomaly detection.
- Understand why blocklists leak and allowlists are more robust.
- Detect a filter with benign-then-malicious probes, differential responses, and
wafw00f. - Bypass it with the core families — URL/Unicode/HTML-entity encoding, case toggling, inline comments, whitespace tricks, and keyword splitting.
- Learn why bypass works — the parser mismatch between filter and sink — and why the durable fix is at the sink, not the filter.
Target: a system you are authorised to test — a PortSwigger Web Security Academy lab with input filters (free account required at portswigger.net), DVWA at medium/high security, or the in-browser filtered challenges in this platform for the encoding step. Never a system you do not own. See [hacking-ethics-and-authorization](hacking-ethics-and-authorization).
Estimated time: twelve to fifteen minutes.
When you are ready, send the Continue signal.