A CDN caching static assets is configured to include a custom request header in its cache key, and shortly after, some users start receiving other users' cached error pages or unexpected content for a shared static URL. What kind of failure is this, and how does it happen mechanically?

## The mismatch that causes it Cache poisoning in a CDN-fronted static hosting setup is a mismatch between what actually determines a response's content and what the CDN uses as its **cache key**. A cache key is the identifier the CDN uses to decide whether two requests should get the same cached response — normally just the URL path (and sometimes select query parameters). The origin, meanwhile, may (correctly or by misconfiguration) produce different responses for requests that share that same cache key but differ in something the key ignores — most commonly a request header. - If the origin's response genuinely depends on, say, a `Host` header, a locale header, or a debug header, but the CDN's cache key is just the path, then the first request to reach a given edge PoP **wins**: whatever response the origin returned for that particular request's headers gets cached under the shared key. - Every subsequent request to that same path at that PoP — regardless of its own headers — receives the cached copy from the first request. - If an attacker can influence what that first cached response looks like, that attacker-shaped response becomes what every other user sees for a completely normal request to that URL, until the cache entry expires or is purged. ## Why static hosting is exposed to it This exists as a risk specifically because of what makes static hosting valuable in the first place: the entire design goal is that one cached response serves many unrelated users' requests. That's a feature under normal operation and becomes the exact mechanism of harm once the wrong response gets cached, because the blast radius of one bad cache write is every subsequent user hitting that same key, not just the one attacker. ## The trade-off: granularity against hit ratio The trade-off underlying this class of bug is between cache-key granularity and hit ratio. | Cache key | What you get | |---|---| | includes every header the origin might theoretically vary on | maximally safe but would fragment the cache into near-uselessness — you'd essentially never get a hit, defeating the purpose of the CDN | | too coarse (URL-only) | maximally cache-efficient but unsafe if the origin's response ever depends on something outside that key | The correct fix is precision, not maximalism in either direction: the CDN's `Vary` handling and cache-key configuration should include exactly the request dimensions the origin's response actually depends on — no more, no less — and, ideally, the origin for pure static assets shouldn't vary its response on arbitrary headers at all, since static assets are the one category of content where 'same URL, same bytes, for everyone' should hold by design. ## Failure modes in production Failure modes in production tend to surface in a few recognizable shapes. 1. **The classic Host-header cache poisoning pattern**, well documented across various CDN/reverse-proxy setups historically: an origin that reflects or uses the `Host` header in some part of its response combined with a CDN that caches by path only, letting an attacker send a request with a manipulated `Host` header that gets baked into a cached response served to everyone. 2. **Caching an error response.** Another is if an edge case — a malformed request, an unusual `Accept` header, an internal server error — produces an error page and that error page gets cached under the same key as the normal successful response, because the CDN wasn't configured to skip caching non-2xx responses, subsequent normal users suddenly get served the error page instead of the real asset, looking like a broad outage traceable to one bad request. 3. **A misconfigured object storage bucket policy** — a related but distinct failure mode. If static assets are hosted in a bucket with overly permissive public-read settings, or if non-public files are accidentally placed in the same publicly-readable prefix as legitimately public assets, those files become world-readable through the CDN just like any other static asset, since the CDN faithfully caches and serves whatever origin returns for a given path. ## The defense pattern A well-known real-world class of incident matching this pattern is web cache poisoning research documented by security researchers against various CDN configurations, where unkeyed inputs — headers, cookies, or response headers the CDN didn't consider part of the cache key — were used to get malicious content cached and served broadly. The practical defense pattern for static content hosting specifically is to keep static asset responses header-independent wherever possible, explicitly configure the CDN to cache only successful (2xx) responses, and treat any `Vary` usage as something to justify and audit rather than something incidental.