Cybersecurity glossary
What is Web Cache Deception?
Learn what web cache deception is, how attackers abuse path suffixes and cache rules to store a victim’s private response, how it differs from web cache poisoning, and how to prevent it.
Definition
Web cache deception is an attack that tricks a shared HTTP cache into storing a victim’s authenticated or otherwise private response under a public-looking URL—often by appending a static-looking path suffix—so the attacker can later retrieve that cached private content without the victim’s session.
Why web cache deception matters
Shared caches speed up the web by storing responses near users. Web cache deception abuses that trust: the cache is supposed to hold public assets, but a carefully crafted URL can make it hold a private page instead.
When that happens, personal HTML, API JSON, or tokens become readable by anyone who requests the same cached URL—without stealing the victim’s cookies after the fact.
How web cache deception works
Attackers rely on a mismatch between how the origin routes a request and how the cache decides what is safe to store.
Attacker crafts a deceptive URL
A path that still hits an authenticated handler is dressed with a static-looking suffix or segment (for example .css or /static/).
Victim opens the URL while logged in
The browser sends session cookies. The origin returns the victim’s private page body despite the misleading path.
Shared cache stores the response
CDN rules keyed on extension or path treat the response as a public static file and store it under that URL.
Attacker retrieves the cached body
Without the victim’s session, the attacker requests the same URL and receives the stored private content.
Impact spreads beyond one click
Any later visitor to that cache key may also see the leaked page until the entry expires or is purged.
Deception vs related cache attacks
Web cache deception
Steal a victim’s private response from a shared cache after path/rule confusion.
Web cache poisoning
Plant a harmful public response that many visitors receive under a normal key.
Cache key mismatch
Origin varies by Cookie or Auth while the CDN keys only on path—enabling both classes of bug.
Over-eager static rules
Caching everything under .js/.css without checking Content-Type or authentication.
Missing no-store
Authenticated HTML allowed into shared storage because Cache-Control was weak or ignored.
Path normalization gaps
Frameworks that strip suffixes after routing still emit private bodies on deceptive URLs.
Common path confusion patterns
| Pattern | Origin behavior | Risky cache behavior |
|---|---|---|
| /account;foo.css | Serves account HTML for the session | Caches by .css extension as public |
| /profile/settings/x.js | Ignores trailing segment; returns settings page | Stores under /…/x.js as static JS |
| /api/me.json.bak | Still hits /api/me with cookies | Treats .bak or unknown type as cacheable |
| Encoded separators (%2f, ;) | Decodes to a dynamic route | Keys on encoded form as a unique static URL |
| Case or normalization diffs | Same handler as /Account | Separate cache slot from the real path |
Security checklist
- Send Cache-Control: private, no-store (or equivalent) on every authenticated or personalized response.
- Configure CDNs to never cache responses with Set-Cookie or Authorization-dependent bodies as public.
- Do not cache solely by file extension; require Content-Type and route class alignment.
- Reject or 404 unexpected suffixes and path junk on dynamic application routes.
- Normalize paths the same way at the edge and at the origin to avoid dual interpretations.
- Exclude HTML and JSON API routes from static asset cache policies.
- Test with a logged-in session against crafted static-looking URLs before and after CDN caching.
- Purge and monitor for unexpected cache hits on authenticated path prefixes.
Limits and pitfalls
Web cache deception depends on infrastructure quirks. A correctly strict CDN may refuse to store the private body even if the origin is confused. Conversely, an origin that returns no-store can still leak if an intermediary overrides caching rules.
Do not confuse a one-off private leak via deception with poisoning campaigns that plant XSS for everyone. Remediation focus differs: deception fixes center on never caching personal responses and aligning path rules; poisoning fixes center on keyed inputs and unkeyed header reflection.
The practical takeaway
Web cache deception turns a shared cache into an accidental dropbox for a victim’s private page by exploiting path and caching mismatches. Keep authenticated content out of public cache policies, refuse deceptive suffixes on dynamic routes, and verify CDN behavior with real sessions—not only with anonymous curl.
Related security terms
Web Cache Poisoning
Seeds a harmful public response for many visitors; deception steals one victim’s private response.
Cache-Control
Directives that should keep authenticated HTML out of shared caches.
Cache Key
How CDNs decide which URL maps to which stored body.
Same-Origin Policy (SOP)
Browser isolation does not stop an attacker who can fetch a publicly cached private page.
Frequently asked questions
What is web cache deception in simple terms?
An attacker sends a victim a link that looks like a static file (for example /account/profile.css) but still returns the victim’s private page. If a CDN caches that response as if it were a public CSS file, the attacker can open the same URL later and read the victim’s cached HTML.
How is web cache deception different from web cache poisoning?
Poisoning stores attacker-chosen content under a key that many users reuse. Deception stores the victim’s own private response under a key the attacker can then request. One spreads malware or XSS; the other steals personal data.
Why do static path suffixes matter?
Many CDNs and proxies cache by extension or path pattern (.css, .js, /static/). If the origin ignores the suffix and still serves the authenticated page, the cache may treat a private HTML body as a cacheable static asset.
Does Cache-Control alone stop web cache deception?
Correct no-store or private on authenticated responses helps a lot, but misconfigured edges that ignore Cache-Control or cache only by URL pattern can still store the body. Defense needs both origin headers and CDN rules.
Who is typically the victim?
A logged-in user who clicks or is redirected to a crafted URL while their session cookies are sent. The attacker does not need the victim’s cookies afterward if the private response was cached publicly.
How do teams prevent web cache deception?
Never cache authenticated HTML on shared CDNs, normalize and reject unexpected path suffixes for dynamic routes, align CDN cache rules with true content type, and verify that personal pages always send no-store or equivalent.
References
Explore authoritative guidance and frameworks related to web cache deception.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.