What still goes through WAF: bypass techniques and how to mitigate

The belief that having a WAF is equivalent to having a security perimeter is one of the most expensive that a technical team can sustain. WAFs operate on representations of requests — receive bytes, interpret according to rules, decide if the pattern matches a known attack. The problem is that between the WAF interpretation and the application interpretation there is a gap. Attackers who are aware of this gap exploit it with techniques that have existed for more than a decade and remain effective because they rely on ambiguities in HTTP protocols, not specific flaws in the product.

How double-encoding bypasses payload inspection

URL encoding is a legitimate HTTP mechanism: ' (single quotes) can be represented as %27. Most WAFs decode this encoding before applying the rules — correct behavior, since the application will also decode it.

The problem appears with double-encoding. The string %2527 decodes in two steps: first to %27, then to '. A WAF that does just one round of decoding sees %27 and considers this to be a harmless representation of single quotes. The application, when processing the request, does its own decoding and arrives at the ' that the attacker wanted to introduce. The payload arrived intact.

Variations include encoding spaces like %09 (tab instead of space, equivalent in many SQL contexts) and mixing uppercase and lowercase encodings that some regex engines do not normalize.

Cloudflare applies request normalization before executing rules — canonicalization that undoes multiple layers of encoding. This mitigates most double-encoding techniques, but the effectiveness depends on the completeness of the normalization applied to each inspected field.

HTTP request smuggling: when WAF and origin disagree

HTTP/1.1 allows two ways to indicate the size of the body of a request: Content-Length, which specifies exact bytes, and Transfer-Encoding: chunked, which sends the body in parts. When two headers are present with conflicting values, the behavior is not defined by the protocol — it is defined by each server's implementation.

A WAF that prioritizes Content-Length and an origin server that prioritizes Transfer-Encoding will disagree about where a request ends up. An attacker controlling this conflict makes the WAF see one harmless request while the server sees two: the first legitimate, the second with malicious content that never passed inspection. HTTP request smuggling has affected multiple commercial WAFs over the years, requiring specific fixes in each.

Cloudflare normalizes requests before forwarding them to origin. For the attack to work on a Cloudflare architecture, the origin server would need to be receiving direct connections — which brings us to the most important and least applied mitigation.

What Cloudflare Genuinely Can't Protect

Business logic is the clearest case. The WAF has no context for its application: it does not know that a transfer of R$50,000 in a rapid sequence is suspicious, that the endpoint /api/export should only be accessed with role admin, or that discount_percentage should not accept negative values. IDOR attacks, manipulation of price parameters, and abuse of authenticationflows arrive as valid requests from the WAF perspective, because they are. This protection belongs to the application.

Zero-days are the second case. When a critical CVE is published, Cloudflare needs time to develop a signature. This interval can be hours or days, and during it the application is exposed even with active managed rulesets. WAF rules do not replace application patches.

The simplest bypass: access the source directly

The entire Cloudflare WAF protection model depends on one condition: traffic must pass through the proxy to be inspected. DNS records in DNS-only mode — the gray cloud on the dashboard — do not pass through the proxy. If the subdomain serving the application is DNS-only, the WAF simply does not exist for that traffic.

The second condition is the source IP. If an attacker discovers the server's real IP, they can connect directly to port 443 with the correct Host header and bypass the edge completely. This IP may have been exposed via historical DNS indexed by SecurityTrails before migration, transparency logs from TLS certificates issued directly to the IP, or email headers sent by the server.

The mitigation is to configure the origin server to accept connections only from the Cloudflare IP ranges published in https://www.cloudflare.com/ips/. A security group or firewall rule that accepts only these ranges eliminates direct contact with the source. For those who want to completely eliminate open ports to the internet, Cloudflare Tunnel establishes an outbound connection from the server to the edge without exposing any IP.

The threat model that needs to be communicated

WAF is effective against a specific category of attackers: those who use automated scanning tools, do not adapt payloads, and seek soft targets at scale. Against vulnerability scanners, generic exploit scripts, and bots that test SQL injection and XSS on every parameter they find, a well-configured WAF blocks the vast majority of attempts without manual effort.

Against a dedicated attacker who studies the application, maps the endpoints, and adapts the payloads specifically for that stack — the protection is different. Bypass techniques exist, some work depending on the state of normalization and the specificity of the rules, and the origin can still be accessed directly if the IP is leaked. WAF buys time, reduces automated attack surface, and adds a layer of visibility into what is being attempted — but it does not replace strong authentication, application input validation, dependency patching, and granular access control at the business level.