Introduction
Web Cache Deception (WCD) is a subtle yet powerful vulnerability that often goes unnoticed in modern web apps. Unlike flashy exploits, it requires no authentication bypass or injection — just clever URL manipulation and a misconfigured cache.
In this article, we’ll explore WCD step by step — including real-world attacker thought process, fuzzing strategies, victim targeting methods, and how it behaves with multiple users. Finally, we’ll show how to properly defend your application.
What is Web Cache Deception?
WCD occurs when a user-specific page (e.g., /account) is served using a deceptive static-looking path like /account/image.jpg. Caching layers (e.g., Cloudflare, Akamai, Varnish) see .jpg and treat it as static, publicly cacheable content — but the backend still serves dynamic, sensitive data based on the user’s session.
Example:
- /account → Dynamic, no cache
- /account/image.jpg → Looks static → cacheable
If a victim visits /account/image.jpg while logged in, their private page might get cached — and served to others.
Step-by-Step: Attacker Workflow
1. Fuzz for Deceptive URLs
The attacker uses tools like ffuf or Burp Intruder to find routes like:
- /account/logo.png
- /account/style.css
- /account/test.jpg
These aren’t real files — they are meant to trick the cache.
The attacker checks:
- Does the server return 200 OK?
- Is the content dynamic (e.g., “Welcome, Alice”)?
- Are cache headers missing or permissive?
- Is “X-Cache: HIT” returned?
2. Confirm the Cache Stores It
The attacker visits a URL like:
https://example.com/account/image.jpg
Then has a logged-in user visit it (via phishing or forum).
If the CDN caches it, the attacker can now access that URL and get the private content.
3. Trick the Victim
The attacker doesn’t know the victim personally — they rely on mass targeting.
Common delivery methods:
- Embed in
<img src="https://example.com/account/image.jpg">on forums or blog comments - Use phishing emails
- QR codes or redirect links in apps
The goal is to get any logged-in user to unknowingly trigger the caching.
4. Retrieve the Cached Data
Once cached, the attacker visits the same URL and sees:
Welcome back, Alice! Account balance: $1,250
Sensitive data has now been leaked.
What If Multiple Users Click the Same Link?
Only one user’s data is cached per deceptive URL.
- If ABCD visits it first → ABCD’s data is cached
- If EFGH visits later and the cache regenerates → EFGH’s data replaces it
The attacker will only see the currently cached version.
What If the Attacker Wants to Target More Users?
They craft multiple URLs:
- /account/a.jpg
- /account/b.jpg
- /account/c.jpg
Each can cache a different user’s data, depending on who clicks them.
Attackers spread them across phishing campaigns, ads, or comments.
Do These URLs Have to Exist?
No. That’s the trick.
The backend will still respond to fake-looking paths like:
- /account/xyz.jpg
And treat them the same as /account, while the cache sees .jpg and stores it.
Most frameworks (Flask, Express, Laravel) allow routes like /account/<path>.
If not validated, they’ll still return user content.
Defending Against WCD
1. Set Cache-Control Headers
For all dynamic/authenticated pages:
Cache-Control: no-store, private
2. Enforce Strict Routing
- Reject or redirect unknown extensions on dynamic routes (e.g., /account/fake.jpg)
- Use allowlist-style route definitions
3. Use Cache Key Varying Headers
Tell caches to differentiate responses:
Vary: Cookie, Authorization
4. Block Unexpected Access Patterns
Log and alert on:
- /account/*.jpg
- /account/*.css
5. Developer Education
Add WCD checks to:
- Threat modeling
- Code review
- Testing pipelines
Summary
| Feature | Web Cache Deception |
|---|---|
| Target | Authenticated users |
| Technique | Trick caching layer with static-looking URLs |
| Example | /account/image.jpg |
| Risk | Sensitive data leak |
| Scope | One user per cached URL |
| Fix | Use no-store, strict routing, vary headers |
Final Thought
Web Cache Deception is a quiet but powerful attack. By manipulating caching rules and URL structures, an attacker can leak private data with a single crafted URL.
Always ensure your dynamic pages aren’t wearing a static disguise.
Written by:
Ahsan Mohsin — AppSec Leader | OSCP | CISSP
Helping businesses build secure, scalable applications.
