What is a Web Application Firewall?
A Web Application Firewall (WAF) sits between your users and your web application, inspecting every HTTP request before it reaches your server. Think of it as a security checkpoint at the entrance of a building — guards check every bag for prohibited items before letting anyone through.
WAFs are designed to detect and block common attack patterns such as SQL injection, Cross-Site Scripting (XSS), path traversal, and remote code execution. They are a widely-deployed security control in enterprise environments and are offered by major cloud providers as managed services.
How Signature-Based WAF Rules Work
Most commercial and open-source WAFs rely on signature-based detection — they maintain a catalogue of known attack patterns expressed as string matches or regular expressions. When an incoming request matches one of these signatures, the WAF blocks the request and returns an error to the client.
For example, a typical XSS signature might look like this in pseudocode:
if request contains "<script" (case-insensitive):
BLOCK requestOr for SQL injection detection:
if request contains "UNION SELECT" (case-sensitive):
BLOCK requestThese rules are generally effective against script-kiddie attacks that copy known payloads verbatim. However, they suffer from a fundamental design weakness: they match text patterns, not semantic intent. The WAF does not understand what the payload will actually do — it only recognises specific character sequences.
Why Signature-Based Rules Can Be Bypassed
The root problem is that the same harmful action can be expressed in many different syntactic forms, while a signature can only describe one pattern at a time. Rule authors must anticipate every possible variation — an essentially impossible task.
Consider the <script> tag. A WAF might block the literal string <script. But the following all produce an executable script block in a browser:
<SCRIPT>— uppercase bypasses a case-sensitive rule<sCrIpT>— mixed case bypasses many case-insensitive rules that only store the lowercase form%3cscript%3e— URL encoding;%3cis the percent-encoded form of<%3Cscript%3E— URL encoding with uppercase hex digits<script>— HTML entity encoding;<is the decimal entity for<<script>— hexadecimal HTML entity encoding
And <script> is not the only attack vector. An attacker who cannot use <script> can often achieve the same result with:
<img src=x onerror=confirm(1)>— no<script>at all<svg onload=alert(1)>— SVG-based event handler<iframe src="javascript:alert(1)">— JavaScript URI scheme
Every time a WAF adds a rule, a motivated attacker tests alternative syntaxes. This is sometimes called the arms race problem: the WAF can never be complete because the attack surface is too large.
WAF Bypass Techniques at a Glance
| Technique | How it works | Example |
|---|---|---|
| Case variation | Change the capitalisation of blocked keywords | <ScRiPt> |
| URL encoding | Replace characters with %HH percent sequences | %3cscript%3e |
| Double encoding | Encode the % sign itself | %253cscript%253e |
| HTML entity encoding | Use < or < for < | <script> |
| Alternative vectors | Use a different HTML element to achieve code execution | <img onerror=...> |
| Attribute obfuscation | Remove spaces, quotes, or use unusual attribute syntax | <img/onerror=alert(1)> |
What You Will Learn in This Lesson
In this lesson you will:
- Examine a set of eight active WAF rules and understand exactly what each one blocks.
- Use the WAF rule tester to experiment with payloads and observe which rules fire.
- Craft a bypass payload that evades the
<scriptrule and would deliver a client-side injection to the application. - Understand why output encoding and Content Security Policy — not WAF filtering — are the correct primary defences against XSS.
Understanding bypass techniques is essential for both offensive security practitioners (who need to test WAF effectiveness) and defensive practitioners (who need to understand WAF limitations when designing a defence-in-depth strategy).