The community
Inside people ask, share what they found and solve together what would block anyone on their own. It's free to join: no account, no plan, no email required.
Free and open. You don't need a BBLABS account to join.
What a WAF is, how to fingerprint it and the most-used bypass techniques —encoding, case toggling, inline comments, HPP, chunked encoding and alternative payloads— applied to XSS and SQL injection. A practical and strictly ethical approach, within scope.
Gorka El Bochi
Founder of BBLABS
Stop reading about bugs and start hunting them
No card · free Academy · cancel anytime
Quick answer: A WAF (Web Application Firewall) filters requests looking for malicious patterns. A "bypass" consists of rewriting your payload so it doesn't match those signatures without losing its effect: encoding it, toggling case, inserting comments, splitting it with HPP or using alternative syntax. It's only done on authorized targets and to demonstrate that the underlying vulnerability exists despite the filter.
A WAF is a layer that inspects HTTP traffic and blocks what looks like an attack, comparing it against signatures and rules (for example, "if you see <script> or UNION SELECT, block"). It's a useful defense, but it has a fundamental weakness: it filters by patterns, it doesn't understand intent. If you can express the same payload in a form the rule doesn't recognize but the browser or the database does interpret, you get through.
Important so you don't fool yourself: a WAF bypass isn't itself a vulnerability. It's the demonstration that a real vulnerability (XSS, SQLi…) is still exploitable despite the filter. Without a flaw behind it, evading the WAF is worthless. What you report is the flaw; the bypass is the proof that the WAF doesn't mitigate it.
Ethics first: all of this is practiced in your own labs or in programs whose scope allows it. Evading a system's defenses without authorization is illegal. Here the goal is to understand the technique to report and to build better defenses.
Before evading, it's worth knowing which category you're facing, because each one has different blind spots:
The common key: all of them, to a greater or lesser degree, decide with incomplete information. The more a WAF relies on rigid signatures, the more room you have to rewrite the payload without it recognizing it.
Before evading, identify what you're facing. Each WAF has recognizable tells:
?q=<script>alert(1)</script>) and observe: a 403, a 406, an "Access Denied", a challenge page? The format gives away the product.wafw00f is the classic for fingerprinting the product; sqlmap has --identify-waf. They give you a hint of the vendor, and each vendor has documented bypasses.Knowing which WAF is in front saves you hours: you aim the techniques at its known blind spots instead of testing blindly.
There's no silver bullet: you combine and iterate. These are the families that work most.
Many rules look for the literal string. Encode it and maybe the rule won't see it, but the server decodes it before using it:
Original: <script>
URL enc: %3Cscript%3E
Double enc: %253Cscript%253E
HTML enc: <script> (depending on context)
For SQLi, URL-encoding key characters or using hex encoding of strings is a common resource.
If the signature looks for union select in lowercase and the SQL engine is case-insensitive, toggle it:
UnIoN SeLeCt password FROM users
Same with XSS: <ScRiPt> can bypass a rule that only looks at <script> in lowercase.
In SQL, MySQL's inline comments split keywords the WAF looks for whole, without breaking the query:
UNI/**/ON SEL/**/ECT
1/**/OR/**/1=1
In XSS, inserting characters the browser tolerates inside the tag can break the signature without breaking execution.
The most robust way: don't use the textbook payload. For XSS, if <script> is blocked, there are dozens of vectors with other tags and event handlers:
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onpageshow=alert(1)>
For SQLi, if OR 1=1 is filtered, there are logical equivalents and alternative functions that achieve the same effect. Understanding the vulnerability from the inside (in the Academy) is what lets you improvise vectors instead of depending on a list.
Sending the same parameter several times can confuse the WAF and the back-end about which to process. If the WAF inspects the first occurrence and the server concatenates or takes the last, you can split the payload across several appearances of the parameter and sneak each half separately.
Fragmenting the body with Transfer-Encoding: chunked, playing with spaces, line breaks or the Content-Type can prevent the WAF from reconstructing the payload the way the back-end sees it. It's terrain that connects with desync techniques like request smuggling.
Many signatures expect a literal space between tokens (UNION SELECT). SQL accepts other separators the WAF may not account for: tabs, line breaks, comments (/**/), or control characters. In SQL, parentheses also work to do without spaces:
UNION(SELECT(password)FROM(users))
Another route is unicode normalization: if the back-end normalizes certain unicode characters to their ASCII equivalent after the WAF has inspected, a "weird" character passes the filter and then turns into the dangerous one. Same with overlong encodings or the mishandling of null bytes in some stacks. The underlying idea repeats: exploit any difference between what the WAF sees and what the application interprets.
47 checks ordered by cost: first what can get you in trouble, then the cheap stuff, and finally the expensive stuff — which is where the big bounties are. I'll send it to your inbox right now.
Unsubscribe in one click, from any email.
Evading a WAF is an empirical process:
Tools like Burp Intruder (to automate variations) and sqlmap's tamper scripts (for automated SQLi, see the sqlmap tutorial) speed up step 5, but the judgment of what to test is yours.
Testing dozens of transformations by hand is tedious, so you automate it sensibly. In Burp Intruder you can load a list of variants of the same payload (case, comments, encoding, alternative syntax) and fire them at the parameter, watching which responses don't trigger the WAF block. The length and status-code columns tell you at a glance which ones passed.
For SQLi, sqlmap's tamper scripts chain these transformations automatically (--tamper=space2comment,randomcase,between), and --identify-waf guides which combination to try. For XSS, payload collections like those in PayloadsAllTheThings give you hundreds of vectors ready to iterate.
Important warning: automating bypass generates a lot of noise and can trigger rate limiting or IP bans. Control the speed, rotate if the program allows it and don't turn the search into a brute-force attack that degrades the service. Automation speeds things up, but the goal is still to understand why a specific variant evades the filter, not to fire thousands blindly.
A flaw that the WAF blocks with the textbook payload but that you demonstrate exploitable with a bypass is worth far more in a report: you prove the mitigation is insufficient and the real risk persists. Security teams value it because it points out that their defense gives a false sense of security.
And on the other side: understanding bypasses also teaches you to defend. A WAF is a layer, not a solution; the real fix is fixing the vulnerability in the code, not trusting the filter.
Is evading a WAF illegal?
It depends on the target. In your labs or in a bug bounty program whose scope allows it, it's a legitimate technique to demonstrate that a vulnerability is still exploitable. Against a system without authorization, it's illegal.
Does a WAF bypass count as a reportable vulnerability?
On its own, usually not. What's reportable is the underlying vulnerability (XSS, SQLi…); the bypass is the proof the WAF doesn't mitigate it. A flaw exploitable despite the WAF is worth more because it shows the defense gives false security.
Is there a universal payload that evades any WAF?
No. Each WAF and each configuration is different. Evading is an empirical process of fingerprinting, observing what it blocks and iterating by combining techniques. Anyone selling you a "magic bypass" is selling you hot air.
How does an app really defend against these bypasses?
By fixing the vulnerability in the code: parameterized queries against SQLi, contextual output encoding against XSS, strict validation. The WAF is a temporary mitigation layer, never the underlying solution.
Bypasses aren't memorized from a list: they're trained by understanding the vulnerability underneath. When you know why an <img onerror> executes or why an inline comment doesn't break a SQL query, generating variants is natural. Study the theory of XSS and SQLi, practice in labs that replicate real reports and follow an ordered path. The WAF bypass is proof that you master the vulnerability, not an isolated trick.
hunters training
labs from real hacks
completions
paid out for these bugs
Create your free account and practice on labs based on real hacks that paid out thousands of euros. The Academy is free forever.
No card · free Academy · cancel anytime
Learn to identify and exploit IDOR (Insecure Direct Object Reference) vulnerabilities in web applications. From the basics to writing effective reports.
Explore the most common techniques for attacking insecure JSON Web Token implementations: from the none algorithm to JKU/JWK injection.
Learn to escalate SSRF vulnerabilities from a low severity to critical impact. Exploitation techniques, filter bypasses and attack chains in cloud environments.