Cybersecurity glossary
What is Web Cache Poisoning?
Learn what web cache poisoning is, how attackers seed harmful responses in shared HTTP caches, how it differs from generic cache poisoning and web cache deception, and how to harden CDNs and origins.
Definition
Web cache poisoning is an attack on shared HTTP caches—such as CDNs and reverse proxies—where an adversary causes a harmful or unintended response to be stored under a cache key that innocent visitors later reuse, delivering attacker-controlled content without a direct compromise of each victim's session.
Why web cache poisoning matters
Shared HTTP caches sit between your origin and the public internet. When they work correctly, they shave latency and protect backends. When web cache poisoning succeeds, one crafted request can change what thousands of visitors receive on a legitimate URL—often without touching the origin again.
Because victims fetch from cache, incident response is harder than a one-off XSS on a single session. The poisoned representation can persist across regions until TTL expiry or a manual purge.
How web cache poisoning works
The attack needs a cacheable route, a way to influence the stored response, and a cache key that honest users will match. Unkeyed headers, query parameters, and normalization quirks supply the leverage.
Attacker probes cacheable routes
They identify URLs cached by a CDN or reverse proxy and test which headers or parameters change the response.
Harmful response is generated
The origin or edge returns XSS, a redirect, or poisoned Set-Cookie influenced by attacker-controlled input.
Shared cache stores the entry
Cache-Control and freshness rules allow storage under a key normal visitors will reuse.
Innocent requests hit the slot
Regular users request the same URL without the attacker's unusual inputs but receive the stored body.
Impact spreads until eviction
TTL expiry, purge, or key rotation ends exposure; until then, the poisoned copy serves at scale.
Distinct concepts compared
| Concept | What is attacked | Typical outcome |
|---|---|---|
| Web cache poisoning | Shared HTTP cache (CDN, reverse proxy) | Many users receive attacker-seeded content on a public URL |
| Cache poisoning (generic) | Any cache layer (DNS, app, HTTP, browser) | Wrong data served from cache under a trusted lookup key |
| Web cache deception | Cache storing a victim's private response | Attacker later retrieves the victim's sensitive page from cache |
| DNS cache poisoning | DNS resolver cache | Clients resolve hostnames to attacker-controlled IPs |
Common enablers
Unkeyed headers
Headers such as X-Forwarded-Host or custom analytics fields that change responses but are omitted from cache keys.
Weak Vary coverage
Responses differ by Accept, Cookie, or encoding but Vary does not list every varying dimension.
Reflected parameters
Query strings or path segments echoed into HTML without being part of the CDN cache key.
Caching personalized HTML
Authenticated pages marked public or cached without cookie variance on a shared tier.
Cached error responses
4xx/5xx bodies that reflect attacker input and remain fresh too long.
Normalization mismatches
Origin and CDN disagree on URL casing, encoding, or header ordering when computing keys.
Defense checklist
- Treat web cache poisoning as distinct from generic cache poisoning and from web cache deception when writing runbooks.
- Never cache cookie-authenticated HTML, Set-Cookie responses, or authorization-dependent JSON on shared CDNs.
- Include every response-varying header and parameter in cache keys or emit precise Vary directives.
- Audit unkeyed inputs on cacheable routes; remove reflection or take those routes off the shared cache.
- Set Cache-Control: no-store on error and diagnostic responses that might echo user input.
- Patch header injection and open redirect flaws that let attackers control stored Location or Set-Cookie.
- Test CDN cache keys after every routing, normalization, or Vary change with adversarial requests.
- Monitor purge volume and anomalous hit ratios on dynamic paths after deployments.
Limits and pitfalls
Disabling all CDN caching eliminates many poisoning paths but does not remove application-level caches or browser behavior. Teams sometimes fix one unkeyed header while leaving others, or purge without fixing the keying bug—allowing immediate re-poisoning.
Web cache deception is a separate threat model. Defenses that stop mass delivery of attacker content may not stop an attacker from retrieving a victim's private cached page if URLs are crafted to look static.
The practical takeaway
Web cache poisoning weaponizes shared HTTP caches: one stored response, many victims, minimal per-user interaction. It is narrower than generic cache poisoning and opposite in goal to web cache deception.
Harden cache keys, stop caching personalized content on shared tiers, and test the CDN the way an attacker would—assuming any unkeyed input on a cacheable route is a future incident.
Related security terms
Cache Poisoning
The broader class of attacks where any cache layer stores harmful entries under trusted keys.
Cache Key
How shared caches index responses; weak keying is the primary enabler of poisoning.
Cache-Control
Directives that decide whether personalized or error responses may be stored at all.
HTTP Header Injection
Injection flaws that can influence stored headers and poisoned redirect or cookie metadata.
Frequently asked questions
What is web cache poisoning in simple terms?
An attacker tricks a shared cache into saving a bad version of a normal page. Later, regular users request that same page and receive the attacker's version from the cache instead of the real one from your server.
How is web cache poisoning different from cache poisoning?
Cache poisoning is the general idea across DNS, application, and HTTP layers. Web cache poisoning specifically targets shared HTTP caches—CDNs, reverse proxies, and similar intermediaries—by abusing how those caches key and store responses.
Is web cache poisoning the same as web cache deception?
No. Web cache deception tricks a cache into storing a victim's private response so the attacker can retrieve it later. Web cache poisoning seeds a harmful response that many unrelated visitors receive when they request a public URL.
What are unkeyed inputs in web cache poisoning?
They are request headers or parameters that change the origin response but are not part of the cache key. Attackers send unusual values, the origin reflects them, the cache stores the result under a normal key, and victims inherit the poisoned body or headers.
What can attackers achieve with web cache poisoning?
Stored XSS, forced redirects, session cookie injection via Set-Cookie, defacement at scale, and delivery of malicious JavaScript through a single poisoned CDN slot that affects thousands of users.
How do teams prevent web cache poisoning?
Fix keying and Vary, avoid caching personalized HTML and Set-Cookie responses on shared tiers, sanitize reflected input, set no-store on errors, validate unkeyed headers, and test CDN behavior with adversarial requests after every routing change.
References
Explore authoritative guidance and frameworks related to web cache poisoning.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.