Why do unkeyed headers and cookies create cache poisoning risk in front-end caches?

Why unkeyed inputs turn shared caches into response confusion points

Front-end caches work by reusing a stored response when they believe a later request is equivalent to an earlier one. That efficiency becomes dangerous when the application uses request data that the cache does not include in its key. If a header or cookie changes what the origin returns, but the cache ignores that difference, the cache can store one user-influenced response and serve it to many others. For readers trying to understand the issue in operational terms, the key question is not whether the header or cookie is “secret”, but whether it can alter shared output without being part of cache identity. That is why this pattern is most dangerous at CDN and reverse-proxy layers, where one poisoned object can be widely reused. In practice, many security teams encounter cache poisoning only after they discover that a response variation was never accounted for in the cache key.

When the content is reflected into markup, redirects, script blocks, or canonical URLs, the result can move beyond a simple integrity problem and become a cross-user exposure issue. The cache is not the root cause on its own; the weakness is the mismatch between what the application varies on and what the cache keys on. NIST Cybersecurity Framework 2.0

How front-end caches are poisoned by unkeyed request data

The mechanics are straightforward. A cache decides whether a request is a hit based on a limited set of attributes such as path, query string, host, or selected headers. If the origin server also uses another header or a cookie to shape the response, then two requests that look identical to the cache may produce different responses at the origin. An attacker can send a request that causes the origin to emit malicious or attacker-controlled content, and if that response is cacheable the front-end layer may store it as the canonical answer for that resource.

• An unkeyed header can affect redirects, language selection, device rendering, or injected links.
• An unkeyed cookie can alter personalised logic that was never meant to be shared.
• Cacheable status codes and permissive TTLs make the poisoned response persist longer than the triggering request.
• Shared delivery layers amplify the blast radius because they sit between one request and many users.

The practical risk is not limited to obvious script injection. Even subtle response differences, such as a changed Location header, a modified base URL, or a fragment of reflected HTML, can create persistent integrity failures when the cache does not vary on the deciding input. Controls that only inspect the application response after the fact often miss this class of issue because the poisoning condition is about cache selection, not just content filtering. NIST SP 800-53 Rev 5 Security and Privacy Controls

Where teams get into trouble is assuming that “the origin is correct” means the cache is safe. That assumption breaks when the origin’s variability is richer than the cache key, and it breaks most cleanly when shared layers are allowed to store responses that were never truly request-independent.

When the risk is highest, and where the usual assumptions fail

Tighter cache normalisation often improves performance but increases the chance of collapsing requests that should stay distinct, so organisations must balance hit rate against response integrity. The standard answer becomes less reliable when a site uses cookies for state, headers for routing, or framework middleware that rewrites output based on request metadata. Industry guidance is still mixed on how aggressively to key on every potentially relevant header, because over-keying can reduce cache efficiency and fragment the cache into near-duplicates.

Risk rises further when response content is shared across unauthenticated and authenticated traffic, when applications vary by geography or device type, or when edge logic rewrites HTML before caching. In those cases, a supposedly “harmless” header can become a control input with shared consequences. The cache can also be poisoned indirectly if a reflected value lands in a redirect target or link that users later trust, even when the body itself does not look obviously malicious.

The main edge case is that not every varying header or cookie must be keyed, but every unkeyed value that influences cacheable output must be treated as a design decision rather than an accident. That distinction matters because the failure is often invisible until the cache starts replaying attacker-shaped output to ordinary users.

Practitioner Guidance

What to prioritise: Inventory every request attribute that can influence cacheable output, then compare that list with the actual cache key rather than the application’s general request handling. The important check is not whether the origin reads the value, but whether the value can change something shared.

What to verify: Confirm that the response varies only on inputs the cache truly distinguishes, and test with paired requests that differ by one header or cookie at a time. If the body, redirect target, or injected markup changes while the cache key stays the same, the control is incomplete.

Common mistake: Treating cookie-based session logic as automatically private. Shared caches can still store partially personalised or attacker-shaped responses if cacheability is not explicitly constrained, so the safer assumption is that any request-derived output needs a deliberate caching rule.

Practitioner takeaway: Cache poisoning is usually a keying problem, not a content problem, and the fix is to make the cache’s equivalence class match every request input that can alter shared output.

Related resources from NHI Mgmt Group

• Why do unsupported front-end frameworks create governance risk for security teams?
• Why do secrets in front-end code create an IAM and NHI risk?
• Why do URL parsing differences between a CDN and an application server create cache poisoning risk?
• Why does exposing a session ID in the front end create a real account takeover risk?