Cache deception is a web attack in which a sensitive response is made to look cacheable so a shared cache stores it and replays it to another user. The core risk is that the cache keys on the URL, while the response varies by authentication state or session context.
Expanded Definition
Cache deception is a web application security issue that appears when a shared cache treats a response as reusable even though the content depends on user-specific state. The attacker’s objective is not to break authentication directly, but to induce the application to return sensitive data in a response that can be stored and later served to another requester. This usually involves manipulating a URL or path so the cache believes the response is safe to reuse while the origin application still generates personalised content.
The distinction matters because cache behaviour is often governed by response headers, URL structure, and intermediary configuration rather than application logic alone. A page may look harmless to a cache while still containing account details, tokens, or other sensitive fields generated after authentication. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because cache and session handling are part of broader access and information protection expectations, even though NIST does not define cache deception as a named term.
Industry usage is still relatively stable, but the boundary between cache deception, cache poisoning, and normal caching misconfiguration is sometimes blurred across vendors and incident write-ups. The most common misapplication is assuming that any cached sensitive page is cache poisoning, which occurs when teams ignore the URL-dependent replay condition and the role of authentication variance.
Examples and Use Cases
Implementing cache controls rigorously often introduces performance and operational overhead, requiring organisations to weigh faster response times against tighter cache bypass rules and more careful header design.
- An authenticated account page is requested with a crafted path that appears static to the cache, causing the shared layer to store a response containing personal profile information.
- A shopping or service portal returns user-specific content under a URL pattern that lacks proper cache separation, allowing another user to receive fragments of the prior session’s response.
- A reverse proxy caches a response because the origin omits the correct cache directives, even though the body includes data derived from a logged-in session.
- A security team validates whether authenticated endpoints are excluded from shared caching by testing origin behaviour against the caching guidance in OWASP Web Security Testing Guide, which is useful for spotting request-path and header weaknesses.
- During a review of an API-backed application, engineers find that cache keys vary only by path and not by authentication context, creating an exposure path for sensitive JSON responses.
These examples show why cache deception is often easier to exploit in layered deployments with CDNs, reverse proxies, and application frameworks that each make separate caching decisions.
Why It Matters for Security Teams
Cache deception matters because it turns a performance feature into a confidentiality failure. Security teams often focus on direct access control flaws, yet a cache layer can silently widen exposure if it stores authenticated responses without a strong separation rule. That makes the issue especially relevant where session cookies, bearer tokens, account summaries, or internal dashboard data are rendered into pages that are still technically cacheable.
From a governance perspective, this is not just an application bug. It touches web hardening, control verification, incident triage, and secure configuration management. The practical response usually includes cache-busting headers, strict vary rules, route design that separates public and private content, and testing that confirms intermediaries behave as expected. A useful adjacent reference is the NIST Cybersecurity Framework, which frames the need for asset protection and secure service delivery, even though it does not name cache deception specifically.
Organisations typically encounter the impact only after a user reports seeing another person’s data or an audit reveals cached authenticated content, at which point cache deception becomes 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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Data-at-rest protection supports limiting sensitive content exposure through caches. |
| NIST SP 800-53 Rev 5 | SC-5 | Denial and flow protection controls relate to intermediary handling of web responses. |
| OWASP Non-Human Identity Top 10 | NHI sessions and tokens can be exposed if cached responses mix identity context. | |
| NIST SP 800-63 | IAL2 | Identity assurance is undermined if authenticated data can be replayed to others. |
| NIST AI RMF | If AI systems serve personalized outputs, cache handling becomes part of trustworthy deployment. |
Ensure cached responses never store sensitive data unless access separation is explicitly enforced.
