Web cache deception occurs when a cache treats a request as a public static asset while the application treats it as a private, personalized page. If a logged-in user is tricked into requesting that URL and the cache stores the response, another person may be able to retrieve the user’s data. The core defenses are to keep personalized responses out of shared caches, align cache and origin URL handling, and verify cache behavior safely on your own deployment.
What web cache deception is—and what it is not
A web cache sits between users and an origin application. When an object is not already cached, the cache forwards the request to the origin and may store the response. Later requests that map to the same cache key can receive that stored response. Web cache deception (WCD) exploits a disagreement between the cache and the origin about what a request means: the origin returns a private dynamic response, but the cache decides it is safe to store.
In a common pattern, an authenticated route such as /account continues to return account data when extra path material is appended, while a cache rule treats URLs ending in a static extension as cacheable. If a victim follows a crafted link, the origin may return their account page and the cache may store it under that URL. An attacker who requests the same cache key may then receive the victim’s response. Whether this works depends on the CDN, cache key, origin framework, routing behavior, and configured rules; no single URL trick applies to every system. PortSwigger explains the general attack mechanics in its Web Security Academy overview.
The victim’s browser is usually part of the attack path: an attacker generally needs to induce an authenticated victim to request the crafted URL. The risk arises when the resulting private response is stored in a cache the attacker can access.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →#1 Best Overall
WCD is distinct from web cache poisoning. In deception, the cache discloses a victim’s dynamic response to an attacker. In poisoning, an attacker causes an attacker-influenced response to be cached and served to other users.
| Aspect | Web cache deception | Web cache poisoning |
|---|---|---|
| What is stored | A victim’s sensitive dynamic response | An attacker-influenced or malicious response |
| Who the attacker aims to reach | The attacker retrieves the victim’s content | Other users receive the poisoned content |
| Typical underlying issue | A cache rule or URL-parsing mismatch lets sensitive content be treated as static | A cache key omits or mishandles an input that changes the response |
| Main preventive emphasis | Keep private responses out of shared caches, align request interpretation, and validate content type | Account for response-varying inputs in cache keys and prevent unsafe responses from being cached |
PortSwigger describes the distinction between these attack classes in its WCD material and web cache poisoning material.
Why cache and origin disagreements happen
Different components can parse or normalize the same URL differently. A cache may classify a request from its extension or directory rules, while an application router may decode delimiters, resolve path segments, or route the request to an authenticated handler. If those interpretations diverge, a URL that looks static to the cache can still produce dynamic content at the origin.
PortSwigger’s “Gotta cache ’em all” research, published August 8, 2024 and updated January 8, 2026, discusses broader parser discrepancies that can enable WCD beyond the familiar route-plus-static-suffix pattern. The exact parsing behavior is implementation-specific, so testing should target the actual cache and origin combination rather than rely on a generic payload.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11How to prevent web cache deception
Keep private dynamic responses out of shared caches
For personalized or otherwise sensitive responses, use Cache-Control: private, no-store where appropriate. Then confirm that CDN configuration does not override the origin’s cache-control headers. PortSwigger’s guidance covers response cache controls and cache-rule risks.
Review extension-based and directory-based cache rules
Do not assume a URL ending in .jpg, .css, or another asset-like suffix necessarily returns a static asset. Where supported, check that the response’s Content-Type is compatible with the requested extension before caching it. Cloudflare documents this approach in Cache Deception Armor; the feature-specific documentation states: “When a mismatch that could result in a Web Cache Deception attack is found, Cloudflare does not cache the response.” This describes that Cloudflare feature, not every cache’s default behavior.
Rank #4
Make URL handling consistent
Review how the cache and origin handle URL decoding, delimiters, dot segments, and path normalization. Align their behavior where possible. If the components cannot be made to interpret a path consistently, do not rely on ambiguous paths for sensitive routes. PortSwigger’s mitigation guidance and its parser-discrepancy research discuss these risks.
Use defense in depth
- Set non-storage controls for private dynamic responses.
- Check that edge rules honor those controls rather than making sensitive responses cacheable.
- Validate response content type against extension-based caching rules when the platform supports it.
- Align cache and origin path interpretation, especially for sensitive routes.
How to test your own system safely
Whether a site is vulnerable cannot be determined from its URL alone. Test only systems you own or are explicitly authorized to assess, and avoid using real users’ sensitive information. PortSwigger offers deliberately vulnerable Web Security Academy WCD labs for learning the attack pattern without probing a third-party service.
Best Value
- Comes with secure packaging
- It can be a gift item
- Easy to read text
- Choose a controlled test route and account. Use an authorized test account and non-sensitive data that lets you distinguish one account’s response from another’s.
- Compare the origin and deployed path. Where your setup permits, inspect the response from the origin directly and through the deployed CDN or reverse proxy. Check whether each layer routes and interprets the tested URL the same way.
- Observe cache behavior. Review cache status and age indicators, response headers, and relevant edge or origin logs. Determine whether the response was fetched from origin or served from cache and whether the cache key is shared across the identities you are testing.
- Compare controlled identities. With separate authorized test accounts, check whether a response associated with one identity can be returned to another under the same cache key. Do not use a victim or a shared user as a test case.
- Use cache busters carefully. A unique query parameter or another platform-appropriate cache buster can help distinguish a fresh origin response from an existing cached object, but first confirm how your cache key treats it. Avoid tests that could overwrite or expose objects to other visitors.
PortSwigger discusses practical cache behavior and testing in its WCD overview. The exact headers, cache-status indicators, and safe test procedure depend on your deployment.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to do if you suspect exposure
- Stop further caching. Disable the affected cache rule or bypass the cache for the sensitive route while investigating.
- Remove potentially exposed objects. Purge implicated cache entries using the procedure for your CDN or proxy.
- Review logs. Correlate requests that may have caused a victim-specific response to be cached with later requests that may have retrieved it.
- Assess the data and users affected. Determine what information the cached responses contained and whether credentials or personal data require your organization’s incident-handling process.
- Correct the underlying mismatch. Fix cache controls, caching rules, content-type validation, or URL interpretation before restoring the affected behavior.
Operational details vary by CDN and application; the available vendor and educational sources do not prescribe one universal incident-response playbook.
What is known about prevalence
The 2020 academic paper “Cached and Confused: Web Cache Deception in the Wild” reports results from its own study. Those findings should be read in the context of the paper’s specific methodology and population, not as a current estimate of how many sites on the internet are vulnerable. No general current prevalence figure is established here.
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.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
