WAF Rate Rules and Cache-Busting Evasion

A WAF rate limit rule scoped to a URL path like /api/v1/search can be trivially evaded by appending random query parameters to each request. The requests /api/v1/search?q=test&_=1234 and /api/v1/search?q=test&_=5678 hit the same backend handler and trigger the same database query, but if the WAF counts them as requests to distinct URLs, each unique URL starts a fresh rate limit counter. An attacker rotating query parameters effectively multiplies the effective rate limit by the number of parameter variations they use.

This evasion technique is the same pattern used to bust CDN caches: appending a random parameter to each request ensures the CDN sees a unique URL and does not serve a cached response. Both the cache-busting and the rate-limit evasion exploit the same property -- WAF and CDN systems that treat full URL (including query string) as the cache/rate-limit key instead of the URL path.

Which WAF Configurations Are Affected

Rate limit rules that match on full URL (including query string) are vulnerable. Rules that match on URL path only (http.request.uri.path in Cloudflare expressions, UriPath in AWS WAF) are not vulnerable to this evasion. The evasion applies to CDN-level caching as well: a search endpoint that is misconfigured as cacheable and does not strip query parameters will generate cache misses for every parameter variation, forwarding all requests to origin.

# Vulnerable Cloudflare expression (matches full URI including query string):
(http.request.uri eq "/api/v1/search?category=books")
# Attacker appends ?_=random and each request gets a fresh rate limit counter

# Correct expression (matches path only, ignoring query string):
(http.request.uri.path eq "/api/v1/search")
# All requests to /api/v1/search, regardless of query parameters, share one counter

# AWS WAF: same distinction
# Vulnerable: using UriPath + QueryString together in rate key
# Correct: using UriPath only as the scope-down statement

Cache-Based Attack Amplification

Cache busting is not only an evasion technique -- it is also used to amplify CDN load. A search endpoint with a high cache hit rate (say, 90%) under normal conditions forwards only 10% of requests to origin. An attacker who appends random query parameters to each request forces the CDN to forward 100% of their requests to origin, effectively multiplying the origin load by 10x compared to normal traffic. The attacker does not need to generate more total traffic -- they just ensure none of it is served from cache.

The Fix: Normalize Before Counting

Rate limit rules should be scoped to the URL path without query string. WAF platforms offer two approaches: use a path-only match expression (which ignores query parameters entirely) or use a URL normalization transform before matching. Cloudflare's http.request.uri.path field is path-only by design. AWS WAF's UriPath field in ByteMatchStatements is also path-only. The issue arises when engineers accidentally use http.request.uri (full URI with query string) or construct rate limit rules from an API endpoint's example URL including query parameters.