What is a cache key and why does it matter for poisoning?

A cache key is the set of request components a cache uses to decide whether two requests are 'the same' and can share a stored response — usually the method, host, and path, sometimes a few headers. Anything NOT in the key is 'unkeyed': it can influence the response but doesn't create a separate cache entry. If an unkeyed input changes the response and that response is cached, the attacker's version is served to everyone who shares the key.

How is cache poisoning different from cache deception?

Poisoning stores a harmful response so it's served to other users (attacker controls the content). Deception tricks the cache into storing a victim's PRIVATE response under a public URL the attacker can then read (attacker steals content). Both abuse the cache, but one pushes a payload out and the other pulls sensitive data back.

How do I prevent web cache poisoning?

Make the cache key include every request input that can change the response — or stop reflecting unkeyed inputs into cached responses at all. Don't reflect headers like X-Forwarded-Host into HTML or links, mark responses that vary by an input with an appropriate Vary header, and never cache responses that depend on request-specific or user-specific data.

Web Cache Poisoning: Serving Your Payload to Everyone

A CDN's whole job is to serve one stored response to many users. Web cache poisoning weaponizes that: an attacker crafts a single request whose harmful response gets cached, and the CDN then serves that poisoned response to every visitor who requests the same URL — until the entry expires.

The mechanism hinges on the cache key. A cache decides two requests are "the same" by hashing a subset of the request — typically method + host + path, maybe a query string. Everything outside that subset is unkeyed: it can still influence the response, but it doesn't create a distinct cache entry. When an unkeyed input changes the response and that response is cached, the attacker's variant is stored under the normal key and handed to everyone.

The classic recipe

Many apps reflect a header like X-Forwarded-Host when building absolute URLs (for scripts, canonical links, password-reset links). That header is usually unkeyed. So:

The attacker requests the homepage with X-Forwarded-Host: evil.com.
The app builds a <script src="https://evil.com/app.js"> from that header and returns the page.
The CDN caches this page under the normal homepage key (the header wasn't part of the key).
Every subsequent visitor gets the cached homepage — now loading the attacker's JavaScript.

One request, stored XSS for the whole site. Variations abuse other unkeyed inputs: X-Forwarded-Scheme to force insecure redirects, unkeyed query parameters, X-Host, X-Forwarded-Server, and cache-key normalization quirks (a "cache key injection" via encoded characters).

What makes a response poisonable

Two conditions must both hold — which is also your map for defense:

An unkeyed input influences the response (a reflected header, an ignored parameter).
The response is cacheable (a cache stores it and reuses it for others).

Break either link and the attack fails.

The fix: key what matters, stop reflecting the rest

// VULNERABLE — building URLs from an attacker-controlled, unkeyed header:
//   const base = 'https://' + req.headers['x-forwarded-host'];
//   res.send(renderPage({ scriptBase: base }));

// SAFE — never trust host-ish headers for content. Use a configured,
// trusted host, so no unkeyed input can reach the cached HTML.
const CANONICAL_HOST = 'https://app.example.com';

app.get('/', (req, res) => {
const html = renderPage({ scriptBase: CANONICAL_HOST });  // fixed, not reflected
res.set('Cache-Control', 'public, max-age=300');
res.send(html);
});

// If a response legitimately varies by an input, either add that input
// to the cache key at the CDN, or announce it with Vary so caches
// don't share entries across different values:
//   res.set('Vary', 'Accept-Language');

The principles

The cache key must cover every input that changes the response. If something can alter output, either key on it or strip it before the origin sees it.
Never reflect unkeyed, attacker-controllable headers (X-Forwarded-Host and friends) into HTML, links, or redirects. Use a configured canonical host and scheme.
Only cache public content. Personalized or request-specific responses get Cache-Control: private, no-store.
Set Vary honestly for every header a response depends on, so caches segment entries instead of sharing a poisoned one.

The one line: if an input can change a cached response but isn't in the cache key, an attacker can poison that entry for everyone — key it or stop reflecting it.

Try it in the web cache poisoning simulation: reflect an unkeyed header to plant malicious JavaScript, watch it get served site-wide, then stop reflecting it and see the entry stay clean. It's closely related to HTTP request smuggling — both abuse the machinery between the user and your app.