Web cache deception

The point to grasp: cache deception exploits a disagreement about the URL suffix. A cache usually decides "cache or not" by extension — .css, .js, .jpg are static, cacheable. But many servers ignore the extra part of the URL and still serve the dynamic page. Combine the two:

• The attacker tricks the victim into opening https://app.example/account/profile.css.
• The server ignores /profile.css and serves the victim's /account/profile page (with personal data).
• The cache sees the .css suffix, thinks it is static, and STORES the response — with the victim's private data.
• The attacker opens the same .../profile.css URL, the cache serves the stored copy → reads the victim's data.

The difference from cache poisoning: poisoning writes a malicious copy into the public cache; deception reads a private copy out of the cache. Both share the root cause — the cache and server disagree — but in opposite directions.

And like the other cache/smuggling topics: the fix is in the cache configuration, not the code. It is a bug of the cache deciding "what to cache" by one rule (the extension) different from the rule the server uses to decide "what to serve".

The mechanism is a URL-suffix disagreement between the cache (deciding by extension) and the server (ignoring the extra part).

sequenceDiagram    autonumber    actor A as Attacker    actor V as Victim (signed in)    participant C as Cache (caches by .css)    participant S as Server (ignores /profile.css)    A->>V: Trick into opening /account/profile.css    V->>C: GET /account/profile.css<br/>Cookie: session=<the victim's>    C->>S: forwards it (not in cache yet)    S-->>C: 200, the VICTIM's profile page<br/>(the server ignores .css)    Note over C: The cache sees the .css suffix → thinks STATIC → STORES the response<br/>(with the victim's private data).    A->>C: GET /account/profile.css (NO cookie)    C-->>A: the stored copy — the VICTIM's data

The key point: the cache stores a login-gated page because it thinks it is static. The attacker needs no victim session to read it — the cache serves the stored copy to anyone asking the same URL, cookie or not.

A conditions table — both must be true to exploit:

The variants live in "the server ignores the extra part": not only .css. /account/profile/xyz (a path suffix), /account/profile;.css (a path parameter), /account/profile%00.css (a null byte), /account/profile.css?x=1 — each is a different disagreement between how the server parses the URL and how the cache decides. This is why an extension blocklist is not enough (like the injection topics).

An account page GET /account/profile behind a login, behind a CDN caching by extension.

# The attacker tricks the victim into opening this URL (via email, a chat link). The victim is signed in.GET /account/profile.css HTTP/1.1Host: app.exampleCookie: session=<the victim's session>

# The server IGNORES ".css" and serves the victim's dynamic profile page:HTTP/1.1 200 OKContent-Type: text/htmlCache-Control: private, no-store       ← the page SAYS do not cache <h1>Alice Nguyen</h1><p>Email: alice@acme.com · Card: **** 4242</p>

# But the CACHE decides by the .css EXTENSION and IGNORES the page's Cache-Control: private.# It stores the response — with Alice's data — under the key /account/profile.css.

# The attacker opens the same URL, with NO Alice cookie:GET /account/profile.css HTTP/1.1Host: app.example(no cookie) HTTP/1.1 200 OK  (from cache)<h1>Alice Nguyen</h1><p>Email: alice@acme.com · Card: **** 4242</p>   ← Alice's data

# Detection: open a private page with a fake static suffix, then open it again with NO cookie.curl -s https://app.example/account/profile.css -b "session=$MY_SESSION" > /dev/nullcurl -s https://app.example/account/profile.css | grep -q "alice@acme.com" \  && echo "CACHE DECEPTION: private data readable with no cookie"

# After the fix: the cache honours Cache-Control: private, AND the server refuses /profile.css# (does not ignore the extra part), AND the cache stores by real Content-Type, not by extension.

Omer Gil — "Web Cache Deception Attack" (Black Hat 2017). The talk that defined the class and showed it working on large services (including a well-known PayPal demo at the time): open an account-page URL with a .css suffix, and the cache stores the page with personal data. It is the source of the conditions table in block 3.

Cache-by-extension-by-default CDN incidents (many reports). Many CDNs default to caching anything with a static extension, and that default overrides the app's Cache-Control: private. So a correct app (setting no-store on account pages) is still deceived if the CDN is configured cache-by-extension. It illustrates block 2's point: the fix is in the cache configuration, not the app code.

Extended research on URL variants (Kettle/Gil, 2020). Showed .css is only one way; a path suffix, a path parameter (;), a null byte, and other URL-parsing differences between the cache and the server all open deception. This is why block 6 says the fix must be "the cache and the server AGREE on what this URL is", not "block the .css suffix".

1. The canary technique — the core check, two steps (like cache poisoning but reading, not writing):

B=https://staging.example.com# Step 1: sign in with a test account, open a private page with a fake static suffix.curl -s "$B/account/profile.css" -b "session=$TEST_SESSION" | grep -q "$TEST_EMAIL" \  && echo "the server ignores .css and serves the private page"# Step 2: open the SAME URL with no cookie — the test data must NOT appear.sleep 1curl -s "$B/account/profile.css" | grep -q "$TEST_EMAIL" \  && { echo "CACHE DECEPTION: private data readable without signing in"; exit 1; }exit 0

2. Try many URL variants — the block 3 table: not only .css:

for u in /account/profile.css /account/profile.js /account/profile/x \         "/account/profile;.css" "/account/profile%00.css"; do  curl -s "$B$u" -b "session=$TEST_SESSION" > /dev/null  curl -s "$B$u" | grep -q "$TEST_EMAIL" && echo "DECEPTION via $u"done

3. Check the server REFUSES paths with an extra suffix (the server half in layer 1b):

# /account/profile.css must be a 404, not serve /account/profile.curl -s -o /dev/null -w '%{http_code}\n' "$B/account/profile.css" -b "session=$TEST_SESSION"# Expect 404. If 200 → the server ignores the extra part, condition 1 of block 3 holds.

4. Check the cache honours Cache-Control: private — this is a CDN config check:

# The private page response must carry Cache-Control private/no-store...curl -sI "$B/account/profile" -b "session=$TEST_SESSION" | grep -i cache-control# ...AND the CDN must honour it (no cache-by-extension). Check the CDN config directly.

5. Check the cache allowlist (layer 2) — confirm the CDN config caches only known static prefixes (/_next/static, /assets), everything else uncached by default. This is a config check, not a code test.

The model mistake, and it is the central one: thinking Cache-Control: private on the app is enough. Many CDNs cache by extension and override that header — so the fix must be in the cache configuration: honour Cache-Control, cache by Content-Type, and allowlist static prefixes.

The location mistake: looking for the fix in the code. Like request-smuggling and web-cache-poisoning, this is a bug of DISAGREEMENT between two infrastructure components (the cache and the server) about "what this URL is", so the fix lives where that disagreement is resolved — the cache configuration and server routing, not a handler.