Web Cache Poisoning
Web cache poisoning tricks a shared cache into storing a malicious response for a normal URL, by supplying unkeyed inputs — headers or parameters the cache ignores — that alter the response.
Definition
Cache poisoning exploits the difference between what the cache keys on and what the response varies with. Unkeyed inputs such as X-Forwarded-Host, odd query parameters, or header-driven redirects change the stored response while mapping to the same cache key. The next visitor for the clean URL receives the attacker-influenced payload.
Context and scope
Exploited against CDNs, reverse proxies, and API gateways on endpoints reflecting header values into redirects, scripts, or error pages. Scanners probe for unkeyed inputs and reflected output pairs.
Common misconceptions
- Only query strings are cached keys — caches vary in keying; headers like X-Forwarded-Host often ride unkeyed while the response reflects them
- HTTPS prevents poisoning — the attack happens inside the TLS boundary at the proxy layer, transport-agnostic
- A short TTL limits damage — one poisoned entry served at edge scale reaches many users within seconds
Anti-patterns
- Reflecting forwarded-host or forwarded-proto headers into redirects and script URLs without validating them
- Allowing arbitrary cache keys while the origin reflects unrecognized query parameters into the body
- Purging on deploy but never auditing which inputs the cache treats as unkeyed
Related concepts
Related examples
Authoritative source
https://portswigger.net/research/practical-web-cache-poisoning
What it is
A cache decides two requests are the same via its key: usually method, path, and some headers. Anything the response depends on but the key ignores is an attack lever. Set a poisoning input, receive a poisoned stored response, then walk away while the cache serves it to everyone requesting the clean URL.
How it works
The attacker finds an unkeyed input with response influence: a Host-derived redirect, a reflected header in an error page, an open redirect URL embedded in the page. They request the URL with the malicious input; the cache stores the resulting response under the clean key. Victims then get scripts, redirects, or content controlled by the attacker.
When to harden
Endpoints where any response content derives from request headers or unrecognized parameters. Validate and pin derived values, strip unkeyed inputs at the edge, and configure Vary plus cache keys so that every response dimension is keyed.
Pitfalls
Cache key normalization differs per product: what is unkeyed on one CDN is keyed on another — test the actual chain. Fat GET bodies and request smuggling produce cache deception cousins. Monitor edge for stored responses containing unexpected hostnames or scripts.