September 26, 2026

Web Cache Deception Part 1: How Caches Become Attack Surfaces

By // l1m1nal_3ntr0py

By // l1m1nal_3ntr0py

4 min read

Part 1 of 2 — Part 2 covers advanced bypass techniques.

What Is a Web Cache?

A web cache sits between the user and the origin server. Its job is simple — store responses for common requests and serve them directly without hitting the server again. Faster response times. Less server load. Better user experience.

Normal flow (no cache):
User → Request → Origin Server → Response → User
      (every request hits the server)

Cached flow:
User → Request → Cache → Response → User
      (cache serves stored response instantly)
      (origin server never involved)

Caches are shared infrastructure. One user's cached response can be served to another user entirely. That shared nature is exactly what makes cache deception possible.

Cache Keys — How the Cache Decides What to Store

Not every request gets cached. The cache uses a cache key to identify requests — typically the URL path and sometimes specific headers.

Cache key example:
GET /static/styles.css
Host: example.com

Cache stores this response and serves it to
ANYONE who requests /static/styles.css

The critical insight: if the cache stores a response keyed to a URL, anyone who requests that URL gets the same cached response.

Detecting Cache Behaviour — The X-Cache Header

Before exploiting anything — confirm the cache exists and understand its state.

X-Cache: hit      → response served from cache
X-Cache: miss     → response served from origin server
X-Cache: dynamic  → response cannot be cached
X-Cache: refresh  → cache was outdated, refreshed from server

Cache-Control: public, max-age=3600
→ response is publicly cacheable for 1 hour

Practical detection in Burp:

Enable Param Miner → Settings → Add dynamic cachebuster. This adds a unique query string to every request so you can test caching behaviour without polluting the actual cache.

Send the same request twice:

  • First response: X-Cache: miss → went to origin
  • Second response: X-Cache: hit → served from cache → caching confirmed!

Cache Rules — What Gets Cached

Caches follow rules to decide what to store. Common rules:

File extensions:
.css .js .jpg .png .ico .woff → static assets → cached
Directory prefixes:
/static/ /assets/ /scripts/ → cached
Specific filenames:
robots.txt favicon.ico index.html → cached
Dynamic paths:
/profile /account /api/user → NOT cached (usually)

The attack surface exists in the gap between what the cache thinks a request is, and what the origin server thinks it is.

Web Cache Deception — The Core Concept

Web Cache Deception exploits discrepancies between how the cache interprets a URL and how the origin server interprets the same URL.

Attacker crafts a URL that:
→ Cache sees as: static file (cacheable!) ✅
→ Origin server sees as: dynamic page (user data!) 💀
Result:
→ Origin server returns sensitive user data
→ Cache stores it (thinks it's a static file)
→ Anyone who requests that URL gets the cached data
→ Attacker requests the URL → gets victim's data!

Attack 1 — Exploiting Static Extension Cache Rules

The simplest form. Append a static file extension to a dynamic URL path.

Normal URL:

GET /api/user/profile
→ Cache: dynamic, skip ❌
→ Origin: returns user profile data ✅

Manipulated URL:

GET /api/user/profile.js
→ Cache: .js extension = static file = CACHE IT! ✅
→ Origin: ignores .js suffix, returns profile data ✅
→ Cache stores profile data keyed to /api/user/profile.js

Attack flow:

Step 1: Attacker crafts URL → /api/user/profile.js
Step 2: Sends link to victim
Step 3: Victim clicks → authenticated request hits cache
Step 4: Cache misses → goes to origin → returns profile data
Step 5: Cache stores victim's profile data!
Step 6: Attacker requests /api/user/profile.js
Step 7: Cache serves victim's profile data to attacker! 💀

Why it works: The origin server uses routing to serve /api/user/profile — the .js suffix doesn't match any route so it's ignored. The cache sees .js and applies its static extension rule.

Attack 2 — Exploiting Path Mapping Discrepancies

Some servers use REST-style URLs where extra path segments are ignored.

REST-style URL handling:

Normal: /api/orders/123
Extra:  /api/orders/123/foo
        → server ignores /foo → returns order 123 anyway

The exploit:

/api/orders/123/foo.css
→ Cache: .css = static file = CACHE IT! ✅
→ Origin: /foo.css ignored → returns order 123 data ✅
→ Cache stores order data!

Even better with cache-specific extensions:

/api/orders/123/foo.ico
/api/orders/123/foo.woff
/api/orders/123/foo.exe

Any extension that triggers the cache rule works.

Detection tip: Use the Web Cache Deception Scanner BApp in Burp to automatically detect misconfigured web caches.

Exploiting Path Mapping — Lab Example

Target URL: /my-account → returns authenticated user data

Test 1: Does the origin ignore extra path segments?

GET /my-account/abc
→ Same response as /my-account? YES → REST-style! ✅

Test 2: Does the cache store it?

GET /my-account/abc.js
→ First request: X-Cache: miss
→ Second request: X-Cache: hit → CACHED! ✅

Exploit:

Step 1: Trick victim into visiting /my-account/abc.js
Step 2: Victim's authenticated session loads their account data
Step 3: Cache stores it!
Step 4: Attacker visits /my-account/abc.js (unauthenticated)
Step 5: Gets victim's account data from cache! 💀

How to Find Web Cache Deception Vulnerabilities

Step by step methodology:

Step 1 — Confirm caching exists:

Send same request twice
Check X-Cache header
miss → hit = cache confirmed ✅

Step 2 — Find dynamic endpoints with sensitive data:

/profile
/account
/api/user
/dashboard
/settings
Any endpoint returning user-specific data

Step 3 — Test static extension appending:

/profile.js
/profile.css
/profile.ico
/profile.png
Check if cached AND returns same data

Step 4 — Test path segment appending:

/profile/test.js
/profile/abc.css
/api/user/123/test.ico

Step 5 — Verify the cache stored sensitive data:

Make first request authenticated
Make second request unauthenticated
If unauthenticated request returns sensitive data = VULNERABLE! 🎯

Impact

What an attacker can steal via cache deception:

→ Session tokens and cookies
→ Personal information (name, email, address)
→ Financial data (account numbers, transactions)
→ API keys and authentication tokens
→ Private messages
→ Any data returned by dynamic authenticated endpoints

The severity depends entirely on what the cached endpoint returns. Account pages, API responses with tokens, and financial data make this Critical severity.

Summary

Web Cache Deception = tricking the cache into storing
                      dynamic authenticated content
Core technique:
→ Append static extension to dynamic URL
→ Cache stores it thinking it's static
→ Attacker retrieves cached sensitive data
Detection:
→ X-Cache header
→ Param Miner cachebuster
→ Web Cache Deception Scanner BApp
Attack types covered:
→ Static extension rules (.js .css .ico)
→ Path mapping discrepancies (REST-style URLs)

Part 2 coming — Delimiter discrepancies, normalization attacks, encoded bypass techniques, and static directory exploitation.

Written by // l1m1nal_3ntr0py