What is Web Cache Poisoning?

Web cache poisoning makes a cache store an attacker-influenced response and later serve it to other users. The cause is usually a difference between request components that the application uses to generate a response and those from which the CDN or proxy builds its cache key.

How does a web cache work?

A cache stores a response under a key commonly formed from host, path and selected query parameters. A later matching request receives the stored response without reaching the backend. Cache-Control, Vary, status, cookies and CDN policy affect whether and how long it is stored. Age, vendor cache-status headers and repeated identical responses provide clues but differ between environments.

How does cache poisoning arise?

1. The attacker finds an unkeyed input: something processed by the application but omitted from the cache key.
2. A request causes that input to affect a redirect, link, script source, error or other response content.
3. The cache considers the response storable and records it under an ordinary public key.
4. Other users requesting the same URL receive the altered content until expiry, eviction or purge.

Reflected input alone is not cache poisoning. It must change a security-relevant response, and that response must be reused for other requests.

Which inputs are often overlooked?

What impact is possible?

Stored responses can redirect to phishing or malware sites, load hostile JavaScript or distribute cross-site scripting to many visitors. Manipulated prices, security headers, API responses and persistent error pages are possible too. If a personalized or authenticated response is stored publicly, it may disclose one user's data to others. Reach and lifetime can make one poisoning request more consequential than an ordinary reflected flaw.

How is cache poisoning prevented?

1. Include all legitimate response variants in one consistent normalized cache key or do not cache the response.
2. Reject unknown host and forwarding headers and configure public base URLs explicitly.
3. Protect personalized, authenticated, error and state-changing responses with suitable cache directives.
4. Validate and encode input for its context; the cache must not be the only XSS or redirect defense.
5. Align CDN, proxy and application behavior for methods, decoding, query handling and path normalization.
6. Version and test cache rules like code and prepare reliable purge procedures.

Code example: do not reflect unkeyed headers into public responses

Vulnerable: the cache key contains only the URL, but the response varies on another header.

$assetHost = $request->header('X-Forwarded-Host');

return response("<script src=\"https://{$assetHost}/app.js\"></script>")
    ->header('Cache-Control', 'public, max-age=600');

Safer:

$assetHost = config('app.asset_host');

return response(view('page', ['assetHost' => $assetHost]))
    ->header('Cache-Control', 'public, max-age=600');

If a legitimate response really varies by language, encoding or another header, the cache must include that controlled dimension in its key. Public caching should normally be avoided entirely for user-specific responses.

How is it tested and handled safely?

Testing starts with a unique cache buster, harmless marker and requests owned by the tester. First prove that a response is cached, then whether an unkeyed input changes that same response. Poisoning a popular production URL can harm real visitors and requires explicit approval and immediate purge capability. During response, remove affected keys and variants, correct both application and CDN behavior, inspect logs for reach and account for browser or client caches where relevant.