Cache Deception labs
Web Cache Deception
What is Cache Deception?
Web Cache Deception tricks a cache into storing the victim's dynamic, authenticated page believing it's a static resource. By adding a static extension or a delimiter to the URL, the origin serves the private data and the cache stores it; then the attacker retrieves it with no session.
Why practice Cache Deception?
Almost every modern app lives behind a CDN, and the discrepancy between how the origin and the cache interpret a URL is surprisingly easy to trigger. A single crafted link can leak the victim's session, API key or personal data to anyone. Typical bounties: $1,000-$10,000.
What will you learn with the Cache Deception labs?
You'll learn to locate dynamic, authenticated content, trick the cache with a static extension or a delimiter, confirm the HIT on the crafted path, force the victim's private response to be cached, and retrieve it from an anonymous session.
Types of Cache Deception we cover
- Path confusion
You add /nonexistent.css to a dynamic, authenticated URL: the origin serves it (ignores the suffix) but the cache stores it because it looks like a static file.
- Delimiter tricks
You use delimiters (;, %00, %23, %3F) the origin and cache interpret differently so the cache sees a static extension and the origin the real page.
- Static extension abuse
The cache caches by extension (.js, .css, .jpg) without looking at Cache-Control; you force that extension onto a private response.
How do you find and exploit Cache Deception?
A practical playbook — from recon to proof of concept.
- 1
Find dynamic authenticated content
Locate pages that return the logged-in user's personal data: profile, settings, API key, balance, tokens.
GET /account/profile → personal data tied to the session - 2
Trick the cache with a static extension
Add a suffix that looks like a static resource. The server serves the real page; the cache treats it as a cacheable file.
GET /account/profile/nonexistent.css - 3
Confirm the caching
Request the crafted path twice and check the cache headers; a HIT on that path indicates the private response was stored.
curl -sI https://target/account/profile/x.css | grep -iE 'x-cache|cf-cache-status|age' - 4
Force caching of private data
Get the victim, with an active session, to visit your crafted URL so their personal response lands in the shared cache.
Link sent to the victim: https://target/account/profile/pwn.css - 5
Retrieve it with no session
Request the same crafted URL from an anonymous session; the cache returns the victim's private data without their cookie.
curl https://target/account/profile/pwn.css (no cookie → victim's data)
Loading labs...
View in full catalog →Frequently asked questions
What is Web Cache Deception?
It's an attack where a cache (CDN or proxy) is tricked into storing the victim's dynamic, authenticated page believing it's a static resource. The attacker induces the caching of that private data and then retrieves it from an unauthenticated session.
How is Web Cache Deception exploited?
You add a static extension or a delimiter to a URL with personal data (for example /account/profile/x.css). The origin ignores the suffix and serves the real page, while the cache stores it because it looks static. If you get the victim to load that URL while logged in, their response is cached and the attacker reads it without a session.
How do you find Web Cache Deception in bug bounty?
Identify authenticated pages with sensitive data and try adding /something.css, /something.js or other suffixes and delimiters. Check with the cache headers (X-Cache, cf-cache-status, Age) whether the crafted path returns a HIT; if so, verify that an anonymous user gets the private data.
How do you prevent Web Cache Deception?
Cache only by real Content-Type and explicit rules, not by the URL extension; mark personal responses with Cache-Control: private/no-store; normalize and validate paths at the origin (reject nonexistent suffixes) and align the URL interpretation between the CDN and the back-end.
Difference between Web Cache Deception and Web Cache Poisoning?
In Cache Deception the attacker tricks the cache into storing the VICTIM's private page and then reads it themselves (theft of the victim's data). In Cache Poisoning the attacker poisons a response with a payload so it's served to ALL users (impact on third parties). Opposite vectors over the same cache layer.
Other related categories
- hunters training
- 650
- labs from real reports
- 50
- completions
- 380
- in bounties practiced
- $200,000
hunters training
labs from real reports
completions
in bounties practiced
Practice Cache Deception in real labs
Every Cache Deception lab replicates a real bug bounty report that got paid. Create your free account, start with the Academy and move to the labs whenever you want.
No card · free Academy · cancel anytime