Web Application Firewalls (WAFs) have become a standard security control for modern web applications. Whether deployed through Cloudflare, Akamai, AWS WAF, Azure WAF, Imperva, F5, or other solutions, their primary objective is to inspect HTTP traffic and block malicious requests before they reach the application.
From a defensive perspective, WAFs provide an additional security layer against attacks such as SQL Injection, Cross-Site Scripting (XSS), Command Injection, Path Traversal, and many other OWASP Top 10 vulnerabilities. However, security professionals performing Vulnerability Assessments, Penetration Tests, Bug Bounty Research, and Red Team engagements frequently encounter situations where a vulnerability exists within the application, but the WAF prevents successful exploitation.
It is important to understand that bypassing a WAF does not necessarily mean breaking the firewall itself. In most cases, bypasses exploit differences in how the WAF interprets requests compared to how the backend application interprets them. A request considered benign by the WAF may still be processed as malicious by the application.
This article explores several practical WAF bypass methodologies frequently observed during real-world security assessments:
- IP Rotation and Reputation Evasion
- Request Size Manipulation using Nowafpls
- Origin Server Identification
- Regex-Based Bypasses
- Encoding and Case Toggling Techniques
This is Part 1 of the series. Future articles will explore parser inconsistencies, HTTP desynchronization, content-type confusion, protocol-level evasions, and advanced cloud WAF bypass techniques.
1. IP Rotation:
Many WAF protections are stateful and source-based. Rate limiting, reputation scoring, behavioral throttling, and temporary IP bans all key off the source address of the request. A single tester hammering an endpoint from one IP looks exactly like an attacker and gets blocked, challenged, or tar-pitted within seconds. IP rotation defeats this entire class of controls by ensuring that no single source address accumulates enough “suspicious” activity to trip a threshold. If every request appears to come from a fresh address, per-IP counters never fill up.
How it’s done in practice The most common approach in professional tooling is to route traffic through cloud API gateways, which present an enormous, constantly-cycling pool of egress IPs:
- Fireprox – Spins up an AWS API Gateway endpoint that proxies your traffic. Because API Gateway rotates its source IPs on essentially every request, a fuzzing tool like ffuf pointed at a Fireprox URL effectively sources each request from a different address. This is the workhorse for IP-based rate-limit evasion.
- IP Rotate (Burp extension) – Brings the same concept into Burp Suite, routing Proxy/Intruder traffic through API gateways spun up across multiple AWS regions. Useful when your testing flow lives inside Burp rather than the command line.
- ShadowClone – Distributes work across serverless compute (AWS Lambda, GCP, Azure functions), giving very high IP variability while also parallelizing the workload.
The mechanism is the same in all three: borrow a large, reputable, frequently-rotated address space from a cloud provider so that the WAF never sees a stable “attacker” to penalize. Although IP rotation is excellent against rate limiting, brute-force protection, and reputation-based blocking. It does nothing against signature-based detection if your payload itself is what’s being matched, rotating IPs just means you get blocked from a thousand addresses instead of one. It’s a delivery technique, not an evasion technique. Combine it with the content-level methods below.
2. Request-Size-Based Bypass (the nowafpls approach):
This is one of the most reliable and underappreciated bypasses, and it exploits a simple economic constraint: inspecting a request body costs CPU and memory. To keep latency low and stay affordable at scale, most WAFs only inspect the first N kilobytes of a request body, frequently 8 KB, sometimes more, sometimes less, depending on vendor and tier. Anything past that limit sails through uninspected, straight to the application. So the trick is brutally simple, pad the request with junk data so the malicious portion falls after the inspection cutoff. The WAF dutifully scans several kilobytes of harmless filler, finds nothing, and waves the request through including the payload sitting at the very end. This only works on requests that carry a body (POST, PUT, PATCH, etc.), but that covers an enormous share of interesting attack surface like login forms, search endpoints, GraphQL, JSON APIs, file uploads, and so on.
Manually padding requests is tedious and error-prone, you have to keep the request syntactically valid so the application still parses it. This is exactly what nowafpls automates. It’s a tiny Burp extension that contextually inserts junk based on the content type, so the request stays well-formed. You select a preset padding amount (or a custom size) at your cursor position in Repeater, and it does the rest. The key principle: each strategy preserves valid syntax for its format, so the server parses the request normally and simply ignores the junk field.
The ecosystem has grown since the original release. WAF Bypadd (a PortSwigger BApp Store extension) does the same padding trick and can hook Proxy, Scanner, and Repeater automatically across URL-encoded, multipart, JSON, and XML.
Practical Workflow:
3. Origin IP Identification:
Cloud WAFs almost always work as a reverse proxy:Client → WAF/CDN → origin server
The protection only exists on the path through the proxy. If you can discover the origin server’s real IP address and reach it directly, you walk straight around the firewall entirely every payload, every rate limit, every rule, gone, because your traffic never transits the WAF. This is consistently one of the highest-impact bypasses precisely because it doesn’t defeat the WAF as it removes it from the equation.
Origins are exposed far more often than teams expect, because the protection model assumes nobody can find the back door.
A typical workflow chains enumerate subdomains, pull passive DNS history from SecurityTrails, pivot on the TLS certificate fingerprint in Censys/Shodan to find every host presenting that cert, then test each candidate IP by sending a request with the target’s Host: header and checking whether the application responds without the WAF’s fingerprints.
Once an IP is discovered:
- Verify ownership.
- Match TLS certificates.
- Compare page content.
- Compare response headers.
- Compare application behavior.
Several real-world Security Analysists, Consultants, Researchers and bug bounty reports have demonstrated successful WAF bypasses through exposed origin infrastructure.
4. Regex Based Bypass:
Signature-based WAFs lean heavily on regular expressions to recognize malicious patterns, a regex for UNION SELECT, one for <script>, one for “../” and so on. Regexes are fast and expressive, but writing one that matches every malicious variant while never matching any legitimate traffic is genuinely hard. Bypasses live in that gap. Techniques like Case Manipulation, Additional Characters, Newline Injection etc as mentioned in the 5th technique also work by identifying Regex detections and identifying bypasses.
5. Encoding and Case Toggling:
One of the oldest WAF bypass techniques involves changing the representation of a payload while preserving its meaning. If the WAF and backend application normalize input differently, detection gaps can emerge.
Example 1 – Case Manipulation
Blocked: <script>alert(1)</script>
Alternative: <ScRiPt>alert(1)</ScRiPt>
Many browsers treat these identically.
Example 2 – Additional Characters
Blocked: <script>alert(1)</script>
Alternative:<<script>alert(1)</script>
Depending on parser behavior, execution may still occur.
Example 3 – Newline Injection
Blocked: javascript:alert(1)
Alternative: java%0ascript:alert(1)
The browser may reconstruct the value while the WAF fails to normalize it properly.
Example 4 – Alternate Syntax
Blocked: <script>alert(1)</script>
Alternative:<script>alert`1`</script>
Different JavaScript syntaxes may evade simplistic pattern matching.
Example 5 – Encoding
Blocked: <script>alert(1)</script>
Alternative (URL Encoded): %3Cscript%3Ealert(1)%3C/script%3E
Alternative (Unicode Encoding): \u0070rompt()
Web Application Firewalls provide valuable protection, but they should never be viewed as a replacement for secure coding practices.
During Vulnerability Assessments and Red Team engagements, testers frequently encounter scenarios where a vulnerability exists but exploitation is initially prevented by WAF controls. Understanding how WAFs inspect, normalize, and process requests can help identify weaknesses in those defenses.
In this article, we explored five practical WAF bypass methodologies:
- IP Rotation and Reputation Evasion
- Request Size Manipulation
- Origin Server Identification
- Regex-Based Evasion
- Encoding and Case Toggling
These techniques focus primarily on detection avoidance and traffic manipulation. In the next part of this series, we will explore more advanced WAF evasion techniques, including parser confusion, HTTP request smuggling-related bypasses, content-type inconsistencies, parameter pollution, JSON-based evasions, and modern cloud WAF weaknesses.
The goal of a security assessment is not simply to bypass a WAF, but to understand whether the underlying application remains vulnerable when defensive controls are removed from the equation.
Leave a Reply