What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Web cache deception is a security flaw that can make a shared cache store a private, personalized response under a URL that looks like a cacheable static resource. If a victim’s authenticated request fills that cache entry and an attacker can request the same cache key, the attacker may receive the victim’s data. The underlying problem is a mismatch between how the cache and the application interpret a URL—not simply the fact that a site uses a CDN.
How web cache deception works
A shared cache, such as a CDN or reverse proxy, can reuse a stored response for later requests. Web cache deception occurs when it stores a response containing user-specific data and then serves that response to someone else.
A common cause is disagreement about a URL’s meaning. An origin application might route both /account and /account/photo.jpg to the same personalized account handler, while the cache treats the .jpg suffix as evidence that the response is a static image. If the victim’s request causes the personalized response to be cached under that URL, an attacker who requests the same cache key may receive it. This is an illustrative pattern, not a universal exploit: whether it works depends on the application’s routing and cache configuration. PortSwigger’s explanation of web cache deception describes this kind of cache/origin interpretation discrepancy.
Other potential mismatches involve path normalization, encoded separators, dot segments, delimiters, or the way an application framework maps paths to handlers. Behaviors differ across cache products, origins, frameworks, and routes. A result observed on one endpoint does not establish that another is vulnerable.
#1 Best Overall
- Comes with secure packaging
- It can be a gift item
- Easy to read text
The typical attack sequence
- A victim is signed in and requests a route that returns personalized information.
- An attacker induces the victim to request a crafted URL, such as one with an unexpected path segment or static-looking suffix.
- The origin returns the victim’s private response, but the shared cache treats the request as cacheable and stores it.
- The attacker requests the same cache key and may receive the stored response.
A static-looking URL alone is not proof of exposure; the route and deployed cache behavior must combine to create the leak. OWASP’s Web Cache Security Cheat Sheet discusses the need to validate cache behavior through the full delivery path.
How it differs from web cache poisoning
Web cache deception is about exposing private content: a personalized response is stored under a cacheable-looking URL. Web cache poisoning instead involves getting a harmful response stored and served to other users, often because some request input changes the response but is not represented correctly in the cache key. Both involve cache design, but their outcomes differ. PortSwigger’s web cache deception material and Cloudflare’s guidance on avoiding web cache poisoning address these related but distinct risks.
How to test for web cache deception safely
Test only systems you are authorized to assess, and use the same CDN and proxy route that serves production traffic. The key is to establish both what the origin returns for a candidate URL and what the shared cache does with that response. There is no universal suffix that proves a site is vulnerable.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Choose a sensitive route and establish its normal response using an authorized test account.
- Through the production delivery path, compare it with carefully selected variants that add unexpected path segments or static-looking suffixes, or exercise relevant normalization cases for that application.
- Use fresh cache keys while testing so an earlier response does not mislead the result. Observe response content and available cache indicators.
- Repeat with distinct authorized accounts or tenants. Confirm that neither identity can receive the other’s response.
- Check behavior after logout or permission changes, and examine relevant headers, query parameters, and purge behavior.
Evidence of the flaw requires the combination: the origin returns the same personalized content for an altered path, and the shared cache stores and replays that response to another requester. The right URL variants depend on the application’s routes and cache rules.
How to prevent web cache deception
Keep sensitive responses out of shared caches
For sensitive responses, OWASP recommends the directive Cache-Control: no-store. For non-sensitive content that may remain in a private cache but should be revalidated, its guidance gives Cache-Control: private, no-cache. Ensure shared-cache configuration does not override the application’s intended policy for sensitive responses. OWASP’s cache security guidance covers these response policies.
Make cache eligibility explicit
Use allowlisted route rules to identify content that is safe to cache, rather than deciding solely from a file extension. Cloudflare also advises caching only truly static files that do not depend on user input in its cache security guidance. Apply the same principle to other CDNs and shared caches: personalized pages should not become shareable merely because a URL looks static.
Make URL handling consistent
Have dynamic routes reject unexpected path segments and static-looking suffixes rather than silently routing them to the same personalized handler. Keep path normalization and parameter handling consistent across the CDN, reverse proxy, framework, and origin. Review whether cache keys include every input that can affect a response, as well as whether authorization is enforced on cache hits. OWASP’s Web Cache Security Cheat Sheet addresses cache keys, URL normalization, and full-path testing.
Use vendor-specific defenses as an additional layer
Cloudflare documents Cache Deception Armor as a cache rule that checks whether a URL extension matches the response’s Content-Type; its documentation says a mismatch indicating possible web cache deception is not cached. This check is a defense layer for the documented configuration, not a substitute for correct response headers, route design, authorization, or testing. See Cloudflare’s Cache Deception Armor documentation (last updated May 6, 2026).
What to do if you suspect an incident
- Identify the affected routes and cache layers, including any CDN and reverse proxy.
- Stop the vulnerable response from being cached by correcting the response policy or cache rule.
- Fix the underlying route, URL interpretation, or cache-key behavior rather than relying only on a temporary cache purge.
- Purge affected entries from the relevant cache layers after the fix, following the system’s incident procedures.
- Re-test the corrected route through the deployed path and across authorized user or tenant identities before restoring any related caching.
OWASP advises purging affected layers and fixing the key or origin behavior before re-enabling caching in its cache-poisoning context; apply incident procedures to the specific system rather than assuming every cache incident has identical remediation. OWASP’s guidance provides the relevant cache-security context.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
