Because a cache may treat two requests as the same even when an unkeyed value changes the response. If that response is stored, later users can receive attacker-influenced content. The risk is highest when application logic reflects headers into URLs, markup, redirects, or scripts that are shared across users through a CDN or reverse proxy.
Why This Matters for Security Teams
Unkeyed headers and cookies are dangerous because front-end caches often make reuse decisions on a narrow set of request attributes, not on every field that can influence application output. If a header or cookie changes what the origin returns, but the cache does not include that value in the cache key, the stored response can be replayed to other users. That creates a shared-content injection path across CDNs, reverse proxies, and edge layers.
This risk is especially relevant in environments that rely on user-specific redirects, locale handling, device detection, or feature flags. A small mismatch between cache keys and response logic can turn a benign optimisation into a poisoning primitive. NHI Management Group’s Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0 both reinforce the same operational point: you cannot protect shared infrastructure by assuming inputs are harmless if they are not part of the identity or trust decision.
In practice, many security teams discover cache poisoning only after a user reports the wrong page, not through intentional testing of cache-key coverage.
How It Works in Practice
A cache-poisoning attack usually starts when the attacker identifies a header or cookie that changes the origin response, such as Host, X-Forwarded-Host, Accept-Language, or a session-adjacent cookie used for routing or personalization. If the cache key ignores that value, the attacker sends a request that causes the origin to emit attacker-influenced content. The cache stores the response under a key that looks normal, then serves it to later users who never sent the malicious header or cookie.
That is why the issue is not simply “headers are dangerous.” The real problem is a mismatch between what influences the response and what the cache considers part of the request identity. The Ultimate Guide to NHIs — Key Challenges and Risks shows how shared secrets and weak lifecycle controls create broad blast radius; the same logic applies to shared cache state when origin behavior is not tightly bounded. Current guidance suggests treating cache variation as a security control, not just a performance setting.
- Key on every input that can change response content, redirect targets, or script output.
- Strip or normalise untrusted forwarding headers at the edge before they reach the origin.
- Avoid reflecting request metadata into HTML, JSON, or redirect responses that can be cached.
- Set cache directives deliberately for personalised or authentication-adjacent responses.
- Test both CDN and reverse-proxy behavior, since each layer may key differently.
The most reliable fixes combine response sanitisation, strict cache-key design, and origin-side checks that prevent user-controlled headers from shaping shared content. These controls tend to break down when multiple proxy layers rewrite headers differently because the effective cache key becomes inconsistent across hops.
Common Variations and Edge Cases
Tighter cache control often increases operational overhead, requiring organisations to balance performance gains against correctness and incident response complexity. Not every unkeyed header is exploitable, and not every cookie should be keyed, because over-keying can destroy cache efficiency and create hard-to-debug fragmentation. Best practice is evolving, but there is no universal standard for which headers must always be included in a cache key.
The hardest cases are environments with conditional rendering, edge-side includes, multilingual applications, and apps that generate redirects based on forwarded headers. Some teams mistakenly assume that authenticated traffic is safe from cache poisoning, but a poisoned public path can still affect logged-out users, shared landing pages, or bootstrap JavaScript. The OWASP NHI Top 10 is useful here because it frames hidden trust expansion as a recurring pattern, even when the immediate issue is caching rather than identity.
For governance, the key question is not “is this header sensitive?” but “can this value alter a response that another user may later receive?” If the answer is yes, then the cache policy, origin logic, and input sanitisation all need to be reviewed together.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Shared trust and hidden influence paths map to cache poisoning risk. |
| NIST CSF 2.0 | PR.DS-6 | Data integrity controls apply when cached responses can be poisoned. |
| NIST SP 800-63 | Identity assurance matters when cookies influence shared responses. | |
| NIST AI RMF | AI risk framing helps evaluate hidden input-output dependencies in shared systems. |
Separate authentication state from cacheable content and avoid caching identity-adjacent responses.
