Web cache poisoning is a flaw where an attacker causes a cache to store a harmful response and then serve it to other users. It usually depends on unkeyed inputs, such as headers or cookies, that change the response but are not part of the cache key. The result can be shared script injection, redirect abuse, or content misdirection.
Expanded Definition
Web cache poisoning is a response integrity problem, not simply a caching bug. It occurs when an intermediary cache, such as a reverse proxy or CDN, stores a response shaped by attacker-controlled input that was never intended to vary the cached object. The key issue is a mismatch between what the application uses to generate content and what the cache uses to identify a unique response.
That mismatch can arise from unkeyed headers, query parameters, cookies, or request metadata that influence rendering, redirects, or security headers without being part of the cache key. In practice, the poisoned object is then replayed to other users until the entry expires or is purged. Formal guidance is usually discussed under cache integrity, input handling, and HTTP response splitting rather than a single standalone security category, so definitions vary across vendors and platform teams. The most common misapplication is assuming that adding a cache layer is safe by default, which occurs when teams do not audit which request inputs can alter a shared response.
Examples and Use Cases
Implementing cache controls rigorously often introduces performance and testing overhead, requiring organisations to weigh lower origin load against the cost of tighter cache-key design and validation.
- An application reflects a request header into an HTML page, but the header is not part of the cache key, allowing one crafted request to poison the page for later visitors.
- A redirect endpoint uses a host-related header to build an absolute URL, and a shared cache stores the attacker-influenced redirect for subsequent users.
- A CDN caches a response that varies on cookie state even though the cache ignores that cookie, causing personalised content or security notices to leak across users.
- A security control page returns different content based on an unkeyed parameter, and the cached version is served broadly after the attacker primes the cache.
- Teams often validate the response path using the NIST SP 800-53 Rev 5 Security and Privacy Controls to tighten input handling, boundary protections, and change monitoring around cache-facing components.
Why It Matters for Security Teams
Web cache poisoning matters because it turns a single request into a shared compromise path. Security teams may think they are dealing with a one-off injection issue, when the real impact is broader: users can receive malicious scripts, incorrect redirects, altered authentication flows, or misleading content from trusted infrastructure. That makes incident scope harder to define and can undermine confidence in the whole delivery layer.
It also exposes a governance gap between application developers, CDN operators, and platform teams. If response variance is not documented and tested, defenders may harden origin systems while leaving edge behaviour untouched. For identity and access journeys, this can affect login pages, session renewal pages, or account recovery flows, where poisoned content can redirect users or distort trust signals. Organisations typically encounter the seriousness of web cache poisoning only after users report inconsistent or maliciously altered content, at which point cache invalidation and boundary review become operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack surface, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS | Protects data integrity and availability, both directly threatened by poisoned cached responses. |
| NIST SP 800-53 Rev 5 | SC-23 | Session authenticity and response integrity controls are relevant when caches serve attacker-shaped content. |
| ISO/IEC 27001:2022 | A.8.28 | Secure coding guidance supports preventing response logic flaws that enable cache poisoning. |
| OWASP Agentic AI Top 10 | Agentic and web-app attack patterns both rely on untrusted input changing downstream behaviour. |
Verify response boundaries and prevent untrusted inputs from influencing shared cached content.
