Web cache poisoning stores a crafted response under a misleading cache key so later users receive attacker controlled content. Web cache deception tricks the cache into storing a dynamic response that should not have been cached, often exposing private data such as tokens or account details. Both rely on request parsing gaps, but the exploitation goal is different.
How the attack goals differ
web cache poisoning and web cache deception both exploit cache and origin parsing mismatches, but they aim for different outcomes. Poisoning tries to seed a malicious response that the cache will serve to other users. Deception tries to make the cache store a response that should have stayed private, so the cache becomes a disclosure path rather than a content injection path.
The distinction matters because the first problem is about integrity and trust in shared content, while the second is about confidentiality and cache scoping. In practice, the same edge, CDN, or reverse proxy may be involved in both, but the abuse condition is not the same.
That is why Web Cache Poisoning and Cache Deception Guide treats cache key design, unkeyed inputs, and safe cache-control rules as separate design problems, not one generic cache bug.
Where the cache and origin disagree
Both attacks depend on a gap between how the cache interprets a request and how the application interprets it. A cache may key on a subset of headers or path data, while the origin uses additional inputs such as host context, routing logic, cookies, or content negotiation. When those views diverge, the cache can be tricked into storing the wrong response for the wrong key.
In poisoning, that mismatch lets an attacker influence content that later appears to be legitimate. In deception, it lets an attacker make a dynamic page look cacheable, often by disguising a private response as a static asset request or another cache-friendly route.
CDN Security Guide is useful here because the practical controls are about edge-to-origin consistency, cache-control discipline, and preventing the cache from normalising requests in a way the origin never intended.
What defenders should test first
The first question is whether the response is meant to be shared at all. If a response can vary by cookie, session, token, account state, or user-specific header, then the safer assumption is that it should not be cached unless the cache key and cache directives are explicitly designed for that behaviour. If a response is public, the priority is verifying that attacker-controlled inputs cannot influence the cached representation.
Host handling is a common place for those faults to surface. A mismatch between the visible request host, forwarded host headers, and origin routing can create misleading cache keys or poison a response that looks valid to the next user. Host Header Attacks and Validation Guide is relevant because the same trust gap can produce both reset-link poisoning and cache poisoning behaviour.
Static asset paths, extension-based caching rules, and overly permissive cacheable responses deserve special attention because they are the usual entry points for deception. For poisoning, any unkeyed input that influences the body, status, redirects, or reflected headers should be treated as a candidate injection surface.
Risk and Threat Considerations
Web cache poisoning can turn a shared delivery layer into a content injection channel, so a single successful request may affect many later users. Web cache deception can expose information that the application intended to keep private, especially when dynamic pages are cached under a path that appears static or harmless.
Failure mechanism: The cache and the origin disagree about what varies, what is safe to store, or which request elements belong in the cache key. That lets attacker-influenced content or private content be written into a shared cache entry.
Impact: Poisoning can deliver attacker-controlled HTML, script, redirects, or other manipulated content to subsequent visitors; deception can leak account details, tokens, or personalised data through a cache hit that should never have existed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | Cache and proxy configuration govern whether responses are cached safely or exposed to poisoning. |
| V14 — Data Protection | Deception can expose private data when dynamic responses are cached incorrectly. | |
| Recommendation — Review cache and proxy configuration to ensure responses vary only on intended inputs. Mark user-specific responses as non-cacheable unless the full variation model is explicit. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | Parsing gaps and host confusion can undermine trust in the request-to-response relationship. |
| SC-28 — Protection of Information at Rest | Incorrect cache storage can persist sensitive response data in shared storage. | |
| Recommendation — Validate request-origin relationships so shared caches cannot be used to misdirect responses. Prevent sensitive response data from being stored in caches without an approved business need. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | CDN and reverse-proxy settings are part of the infrastructure that must enforce safe caching. |
| Recommendation — Harden CDN and proxy settings so edge caching cannot diverge from origin intent. | ||
Practitioner Guidance
What to verify: Confirm which responses are actually cacheable, which request fields affect the response, and whether the cache key includes every input that materially changes content. If a response varies by user state, session, or sensitive headers, treat default caching as unsafe until proven otherwise.
Decision rule: If the attack path depends on a parsing mismatch, fix the mismatch first, then validate the cache behaviour with the origin's actual routing and variation logic. If you cannot explain why a response is safe to cache for a different user, do not rely on the cache to make that decision for you.
What practitioners underestimate: Web cache issues are often introduced by edge configuration, framework defaults, or proxy behaviour rather than by the application code alone. The safe pattern is to test the complete path from browser to CDN to origin, because the vulnerable interpretation may only appear when all three layers are combined.
Practitioner takeaway: Treat poisoning as a shared-content integrity problem and deception as a private-data caching problem; both are cache key failures, but they demand different verification and containment choices.
Related resources from NHI Mgmt Group
- What should security teams do first when auditing for web cache poisoning risk?
- How should security teams defend against web cache poisoning when CDNs and origin servers parse URLs differently?
- Why do cache poisoning attacks keep working in modern web environments?
- Who is accountable for fixing cache-related exposure in web applications after a framework vulnerability is disclosed?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org