Web Cache Deception — Advanced Bug Hunter's Guide

Introduction

Web cache deception is a high-impact vulnerability where attackers trick caching mechanisms into storing and serving sensitive content, enabling unauthorized data access or account takeover. This guide covers advanced detection and exploitation techniques to help security professionals safeguard their applications.

In This Guide

• Web Cache Deception fundamentals
• How WCD works and its impact
• Cache keys and caching behavior
• Cache detection and manual verification
• Advanced bypass techniques and special headers
• Encoded paths and query parameter manipulation
• Extensive payloads, delimiters, and URL tricks
• Step-by-step exploitation methodology
• Real-world attack examples
• Mass hunting and automation commands
• Prevention and mitigation strategies
• Recommended tools and practice labs

What is Web Cache Deception?

Web Cache Deception (WCD) occurs when an attacker manipulates a caching system such as a CDN, reverse proxy or browser cache into storing sensitive content under what appears to be a harmless static resource. When another user requests that resource the cache serves the sensitive data instead, exposing information that should remain private. This typically arises from improper cache configurations, missing or incorrect security headers or flaws in how URLs and query parameters are processed.

A Simplified WCD Attack Flow

• The website uses a CDN or reverse proxy (e.g., Cloudflare, Akamai, Fastly) that caches static files like .css, .js, .jpg
• Private pages exist (e.g., /account, /profile, /settings) that should never be cached
• Attacker appends a fake static file extension to a private endpoint

4. The cache sees .css → treats it as a static resource → stores the HTML content of the private page
5. Any unauthenticated user visiting that URL later gets the cached private content

Impact

• Exposure of personal information
• Session hijacking
• Authentication bypass
• Complete account takeover

Types of Caches

Cache Control Headers

Cache Keys

Caches use keys to identify and store resources. These keys are typically based on:

• The full URL (including query parameters)
• Selected headers (Host, User-Agent, Accept-Encoding etc.)
• Cookies (in some configurations)

Using Cache Checker Tools

Online tools like giftofspeed.com can help determine if a resource is being cached. These tools analyze HTTP responses and provide insights into caching behavior. You can enter the full URL with your cache key to test it or use the base domain to discover which resources are currently cached.

Key Headers to Analyze

HIT means the content was served from the cache.
MISS means the content was fetched from the origin server.
X-Cache: dynamic indicates the response was generated dynamically.
X-Cache: refresh shows that the cached content was outdated and refreshed.

Manual Verification Techniques

• Request-Response Analysis: Make multiple identical requests and compare responses
• Cache Busting: Add unique parameters ?v=123 to URLs and observe if responses change
• Timing Analysis: Cached responses typically have faster response times

The server processes /account.php as a PHP script, but due to the added /poc.css suffix the CDN caches the HTML/PHP-generated sensitive content as if it were a static CSS file. Anyone visiting the URL later gets the cached sensitive data without authentication.

Burp Request

GET /account.php/poc.css HTTP/1.1
Host: vulnerable-example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0)
Accept: text/css,*/*;q=0.1
Cache-Control: no-cache

Burp Response

HTTP/1.1 200 OK
Date: Mon, 11 Aug 2025 09:40:18 GMT
Content-Type: text/css
Content-Length: 412
Cache-Control: public, max-age=86400
X-Cache: HIT

/* Cached response exposing sensitive data */
body { background-color: #fff; }

/* Attacker view */
username: johndoe@example.com
email: johndoe@example.com
session_token: 9f73b21d2e934f6e4cbdc8d83c4e9210

The server processes /account.php as a PHP script, but due to the added /poc.css suffix the CDN caches the HTML/PHP-generated sensitive content as if it were a static CSS file. Anyone visiting the URL later gets the cached sensitive data without authentication.

Identifying Cacheable Endpoints

When looking for web cache deception bugs, some endpoints are more likely to be vulnerable. Start by checking these common sensitive paths first:

File Extensions to Test

When testing for cache deception, append various file extensions to sensitive endpoints to make them appear as static resources:

Path Poison

Obfuscated Path

Using Delimiters

Force Cache with Special Headers

These headers can deceive caching systems into handling a dynamic response as if it were tied to a different cacheable URL:

Bypassing with Encoded Paths

URL encoding can confuse backend vs frontend behavior, potentially creating cacheable paths that access sensitive data:

Injecting Cache Keys with Query Parameters

Many CDNs cache based on certain query parameters. Attackers can exploit this by crafting URLs:

Delimiters and Special Characters

Use these delimiters and special characters to creatively manipulate URLs and bypass cache rules:

Special Delimiter Testing

Try inserting these special delimiters right before file extensions to see if caching systems mishandle the URLs:

Encoded Delimiter Testing

Use URL-encoded special characters before file extensions to bypass cache rules:

Advanced Testing Combinations

Test URLs by appending file extensions combined with /* to trick caches into storing sensitive responses:

Real-World Examples

Profile Page Poisoning

Discovery: A tester noticed that /user/profile contained sensitive user information.
Testing: The tester appended a static extension to the URL: /user/profile.css
Verification: After logging out and accessing /user/profile.css in incognito, the same sensitive data was returned.
Root Cause: The CDN was caching based on the file extension, treating the .css URL as a static resource while the backend still processed it as a profile request.

API Endpoint Manipulation

Discovery: An API endpoint at /api/user/data returned JSON with user-specific information.
Testing: The tester added a cache-busting parameter with a static extension: /api/user/data?callback=static.js
Verification: When accessed without authentication, the endpoint returned the cached user data.
Root Cause: The CDN was configured to cache based on the presence of certain query parameters.

Simple Exploitation Checklist

1. Identify private endpoint
2. Append static-like extension
3. Test caching: curl -I https://target.com/account.css
4. Look for cache hit headers
5. Verify sensitive content exposure
6. Try multiple variations for bypass

Automation Commands

Use these one-liner automations to hunt Web Cache Deception vulnerabilities at scale:

This pipeline does the following: Gets all URLs for the target domain using gau. Filters URLs to only keep those with sensitive paths like /account, /profile, /admin, etc. Saves the filtered URLs to a file. Appends /style.css to each URL to mimic a static file (a common cache deception trick). Uses httpx-toolkit to check which URLs respond with HTTP 200, showing live pages that might be cached improperly.

Recommended Tools