**Note: The content in this article is only for educational purposes and understanding of cybersecurity concepts. It should enable people and organizations to have a better grip on threats and know how to protect themselves against them. Please use this information responsibly.**
Web Cache Deception (WCD) is a vulnerability that occurs when an attacker can trick a caching system (such as a CDN or reverse proxy) into caching dynamic content that should not be cached, such as user account information or API keys.
In a typical WCD attack:
1. Victim accesses crafted URL – GET /profile;a.js. URL is designed to look like a static resource (.js).
2. Origin server processes the request. Ignores ;a.js, treats it as /profile. It returns the victim’s private profile data.
3. Cache receives response. It sees .js in the URL → assumes it’s cacheable. So it caches the user-specific response.
4. Attacker accesses the same URL – GET /profile;a.js. Cache serves the victim’s cached data to the attacker.
Walkthrough
Lab: Exploiting path mapping for web cache deception | Web Security Academy
In this lab, our goal is to get the API key of user Carlos using this technique.
Step 1: Log in as Wiener by clicking on My account.
Username: wiener
Password: peter
Step 2: Once logged in, you’ll be redirected to your account page (/my-account). This confirms /my-account returns user-specific (sensitive) data.
Step 3: Send /my-account to Repeater. In Burp, go to Proxy > HTTP History. Right-click the GET /my-account request. Select Send to Repeater.
Step 4: Add a fake segment to the URL in Repeater, change the path from:
GET /my-account to GET /my-account/abc
Click Send.
This shows the origin server is ignoring the added path and is still mapping to /my-account.
Step 5: Add a static extension to trigger caching. Change the URL to: GET /my-account/abc.js
Click Send. Look at response headers.
X-Cache: miss → First request, not cached yet
Cache-Control: max-age=30 → Can be cached for 30 seconds
Step 6: Re-send the request. Click Send again within 30 seconds.
You should now see:
X-Cache: hit
This confirms the cache stored your API key response for 30 seconds under this .js path.
Step 7: In the browser, click “Go to exploit server”. In the Body field, paste the following:
<script> document.location =”https://0a7200b004a9d5a38096120e00c000df.web-security-academy.net/my-account/wcd.js”</script>
Use a new, unique name (like wcd.js) instead of abc.js to avoid reusing your cache.
Click Deliver exploit to victim.
This makes the victim user Carlos load that crafted path, causing his API key to be cached.
Step 8: Obtain Carlos’ Cached API Key
https://0a7200b004a9d5a38096120e00c000df.web-security-academy.net/my-account/wcd.js
You should now see Carlos’ API Key in the response.
Step 9: Click on “Submit solution“. Paste Carlos’ API key to complete the lab.
Impact
- Exposure of sensitive assets (e.g., API keys, session tokens, personally identifiable information).
- Account takeover, privilege escalation, or information leakage.
- Acute danger when dealing with applications that utilize shared caches, or CDNs (such as cloud-based CDN caching, since another user is likely going to get the cached document as well).
- Could bypass the traditional access controls if the content being served is publicly cached.
Mitigation Strategies
- Cache-Control headers (strictly cache-control): Use Cache-Control: no-store and Cache-Control: private for sensitive endpoints (/profile, /account, /cart).
- Path Handling Consistency: Ensure the origin server and caching layers all interpret URLs in the same way. e.g. Do not ignore path segments like ;abc.js.
- Block static extensions from dynamic pages: Specify valid cacheable file types (.css, .js, .jpg) as allowlist to disallow arbitrary suffix on sensitive endpoints.
- Implement authentication-aware caching by including session tokens or cookies in cache keys. This ensures that cache entries are user-specific and prevents cross-user data leakage.
CDN Misconfigurations and Industry Response
- WCD attacks in many applications happen to involve existing applications that utilize Content Delivery Networks (CDN) (e.g., Akamai, Cloudflare, Fastly) to serve their content.
- Attackers utilize the difference between the CDN’s caching rules and the origin server logic.
- Following the 2017 WCD demonstrations, several organizations mitigated risk by disabling caching for authenticated sessions.
Conclusion
Cache deception is possible because the cache can interpret paths differently from how the server can. For example, add an arbitrary static extension (.js, .css, …) to a dynamic endpoint, and the cache would not know how to interpret its content, deceiving it to cache private content. If a victim loads the crafted URL, they will have their data cached and accessible to the attacker. Therefore, always examine for:
- Loose cache-control headers
- Static extensions on dynamic content
- Differences in how paths are interpreted.
Caught feelings for cybersecurity? It’s okay, it happens. Follow us on LinkedIn and Instagram to keep the spark alive.
