Join our Newsletter — 33% off our NHI Course

Cache Key Poisoning

A cache key poisoning issue occurs when shared infrastructure stores or serves a response using incomplete request identity, so different users can receive the same cached object. In identity security, this becomes dangerous when the object contains tokens, credentials, or other privilege-bearing data.

What Cache Key Poisoning Is and Why It Matters

cache key poisoning happens when a shared cache uses an incomplete or misleading request identity, so one response is stored under the wrong key and later served to other users. The security problem is not just stale content, but cross-user exposure when the cached object contains sensitive or privilege-bearing data.

This is most dangerous in systems where responses vary by authentication state, tenant, locale, headers, cookies, or query parameters, yet the cache only keys on part of that context. A cache that looks efficient from the outside can still become a trust boundary failure if it cannot distinguish who the response was really meant for.

How the Poisoning Condition Appears

The failure usually starts when application logic, reverse proxies, CDNs, or intermediary caches treat requests as equivalent even though they are not. That can happen when important request attributes are ignored, normalised too aggressively, or stripped before caching logic decides reuse.

In practice, the attacker does not need to break the cache itself. They only need to find a request shape that causes a cacheable response to be generated under a key that other users will later hit, which makes this a request-shape and cache-boundary problem rather than a classic payload-only injection issue.

Cache-related attacks often overlap with broader web manipulation patterns, so it is useful to understand them alongside Web Application Attacks Guide content that covers web cache poisoning and related request interpretation flaws.

Identity, Session, and Data Exposure Consequences

Cache key poisoning becomes especially severe when the cached response carries anything that should be unique to one principal, such as session material, bearer tokens, account details, or privilege-sensitive workflow data. If that object is replayed to the wrong user, the impact can move from information disclosure into account compromise or unauthorized action.

The exposure is often subtle because the response may still look valid, just not valid for the recipient. That makes cache poisoning dangerous in high-throughput environments where users trust the cache as an invisible optimization layer and do not expect it to become a source of cross-session contamination.

When the poisoned path involves token handling, request routing, or workflow state in automation platforms, the surrounding control model matters as much as the cache implementation. The GitHub and GitHub Actions Security Guide is a useful adjacent reference for understanding how cache-related trust mistakes can interact with workflow secrets and execution context.

Prevention and Validation of Cache Boundaries

Defence starts with making cache keys faithfully represent the request dimensions that change response meaning. If identity, host, path, method, query string, selected headers, or tenant context affect content, those factors need to be reflected consistently in cache behaviour rather than assumed away for performance reasons.

Organisations should validate cache behaviour the same way they validate authentication or authorisation logic, because the business effect can be similar even when the technical layer is different. That includes checking internet-facing edges, CDN behaviour, origin headers, and any middleware that can rewrite requests before the cache sees them.

For broader DNS and edge-layer trust issues that can shape how responses are routed or reused, the DNS Security Guide is a useful companion reference, especially when cache exposure is amplified by resolution, routing, or intermediary control failures.

Detection, Review, and Compensating Controls

Detection is strongest when teams compare what the cache served with what the origin would have produced for the same request under different identities or contexts. Suspicious signs include unexpectedly shared objects, inconsistent personalization, unusual cache hits on sensitive endpoints, and user reports of seeing data that belongs to another session or tenant.

If a patch or code change cannot be applied immediately, teams should reduce blast radius by disabling caching for sensitive responses, tightening vary logic, segmenting high-risk endpoints, and increasing logging around cache key construction and response reuse. After an incident, review whether credentials, sessions, API keys, or other privileged material may have been exposed and rotate them if there is any credible chance of reuse.

Where web-layer trust boundaries are involved, the GitHub and GitHub Actions Security Guide also helps frame how cached artefacts, workflow secrets, and execution context can become part of the same compromise chain.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP ASVS V4 — API and Web Service Cache key poisoning affects how web responses are produced and reused.
Recommendation — Validate response caching rules and request variance handling for web and API endpoints.
OWASP API Security Top 10 API8 — Security Misconfiguration Incomplete cache keys are a misconfiguration that can expose responses across users.
Recommendation — Review API and gateway caching behaviour for unsafe response reuse across principals.
CIS Controls v8 CIS-16 — Application Software Security Application-layer response handling must avoid cross-user data exposure through caching.
Recommendation — Test application and edge caching controls for unsafe reuse of personalised responses.
NIST SP 800-53 Rev 5 SC-23 — Session Authenticity Poisoned cache reuse can undermine trust in session-bound responses and identity context.
AC-3 — Access Enforcement Serving cached privileged data to the wrong user bypasses intended access decisions.
Recommendation — Bind sensitive responses to the correct session and reject reused content across identities. Ensure cached responses cannot bypass access decisions for protected content.