Web Cache Deception Cheat Sheet

Path confusion, delimiter tricks, and static-extension abuse for finding and exploiting Web Cache Deception (WCD) during authorized testing — plus a full discovery-to-exploitation workflow. (37 payloads)

Try it interactively with the HTTP Header Analyzer

Static-Extension Abuse

(6)

GET /my-account/foo.css HTTP/1.1

The classic Web Cache Deception primitive (Omer Gil, 2017). Append a static-asset extension to a dynamic, authenticated path. If the origin ignores the trailing segment and still serves /my-account, but the CDN sees a .css URL and caches it, the victim's personal page is stored publicly. The attacker then requests the identical URL unauthenticated to read it.Origin maps the path loosely; cache keys on extension

GET /api/users/self/profile.js HTTP/1.1

Target JSON/API endpoints that echo the same body regardless of a trailing path segment. Many caches treat *.js / *.css / *.json as static and store the response with full tokens, email, and PII — turning a personalized API response into a public cache entry.API returns identical body for any path suffix

GET /account/settings.jpg HTTP/1.1

Image and font extensions (.jpg .png .gif .ico .woff2 .svg) are almost always in default CDN cache rules and are rarely scrutinized. Cycle through every cacheable extension — one of them frequently matches a broad rule the team forgot about.Image/font extensions = widest default cache match

GET /account/avatar.css.jpg HTTP/1.1

Double-extension. If the cache only inspects the final extension while the origin's router or static handler keys on .css (or simply ignores both), you satisfy a static rule the origin never intended for this route.Cache reads last extension, origin reads first

GET /account/.css HTTP/1.1

Bare-extension trick. Some routers normalize a dot-segment away and serve /account, while the cache classifies the request as a CSS asset. Test the empty-name variants (/.css, /.js) when full filenames are blocked.Router strips dot-file, cache keeps extension

GET /robots.txt/../my-account HTTP/1.1

Static-prefix confusion: lead with a known-cached path (robots.txt, /static/, /assets/) then traverse back to the dynamic resource. Caches that key on the static prefix store whatever the origin ultimately renders after collapsing the traversal.Cache trusts the static prefix, not the final route

Path-Parameter & Delimiter Confusion

(7)

GET /my-account;foo.css HTTP/1.1

Path-parameter (matrix) confusion. The semicolon is a path-parameter delimiter (RFC 3986). Java/Spring, Tomcat, .NET, and PHP often strip ;foo.css and route to /my-account, while the cache treats the whole token (ending .css) as a static file. The single most productive WCD delimiter.Spring/Tomcat/.NET strip matrix params; cache does not

GET /my-account%3Bfoo.css HTTP/1.1

URL-encoded semicolon (%3B). When the literal ; is normalized identically by both layers, the encoded form may decode only at the origin (which strips it) but stay literal at the cache (which keeps the .css), recreating the discrepancy.Encoded delimiter decodes at one layer only

GET /my-account%23foo.css HTTP/1.1

Encoded fragment delimiter (%23 = #). Some origins decode %23 to # and truncate the path to /my-account; the cache leaves %23 literal and sees a .css filename. Pair with %3f for full delimiter coverage.Origin decodes #, truncates; cache keeps literal

GET /my-account%3Ffoo.css HTTP/1.1

Encoded query delimiter (%3F = ?). If the origin decodes it and parses foo.css as a query string (serving /my-account), while the cache normalizes on the literal path, the response gets stored under the .css key.Origin treats %3F as query start

GET /my-account%2ffoo.css HTTP/1.1

Encoded slash (%2F). Some caches decode %2F to / and key on /my-account/foo.css (a cacheable-looking subpath) while the origin keeps it encoded and routes to /my-account, or vice versa. A core building block of path-traversal WCD.Slash-decoding mismatch between cache and origin

GET /my-account%00.css HTTP/1.1 / /my-account%0a.css

Null-byte and newline delimiters. The origin may truncate at %00/%0a and serve the dynamic page, while the cache keeps the full string ending in .css. Also try %09 (tab), %20 (space), and %2e (dot) — different stacks split on different control bytes.Control-character truncation discrepancy

GET /my-account/%2e%2e/static/foo.css HTTP/1.1

Encoded path traversal toward a cached directory. The cache collapses ../ and keys the request as /static/foo.css (a definitely-cached path); the origin resolves it back to the dynamic /my-account. Map the exact normalization order with a cache buster first.Cache collapses traversal into a static dir

Discovery & Cache-Rule Probing

(6)

GET /my-account/cb-uniq1234.css HTTP/1.1

ALWAYS lead with a unique, random filename/cache-buster so you poison only your own cache key and never serve a victim's private page publicly during testing. Confirm the deception with this buster, then reason about real exploitation separately. Mandatory safety step.Authorized-testing safety: isolate your own key

X-Cache: HIT | CF-Cache-Status: HIT | Age: 42

Read response headers to confirm a cache exists and that your crafted request was stored. X-Cache/CF-Cache-Status/X-Cache-Status flip from MISS to HIT on the second identical request; a non-zero, increasing Age proves the response is being served from cache, not regenerated.Confirm caching: send the same request twice

Cache-Control: no-store / Pragma: no-cache

Send no-store to force a fresh origin fetch so you can see what the back-end actually returns for your crafted path before the cache stores anything. Compare the origin body against the later cached body to prove the deception is real.Origin-fetch baseline before reasoning about cache

GET /my-account/foo.css HTTP/1.1
Cookie: session=VICTIM

The core test: request the dynamic path + extension WITH your own valid session, confirm the personal response is cached (Age/HIT), then re-request the EXACT URL with NO cookies (incognito / second profile). If you still receive the authenticated body, deception is confirmed.Authenticated store, unauthenticated read = confirmed

GET /static/legit.css HTTP/1.1 → inspect Cache-Control / s-maxage

Fingerprint the real cache rules first. Request known static assets and read their Cache-Control, s-maxage, and Vary. Whatever extensions/paths the CDN caches for genuine assets are exactly the suffixes to graft onto dynamic routes.Reverse-engineer the rule set from real assets

for e in css js png ico svg woff2 json txt pdf; do curl -s -o /dev/null -w "%{http_code} $e\n" "https://target/my-account/x.$e"; done

Brute-force the cacheable extension list against a dynamic path. Pair with a second pass that diffs X-Cache/Age across requests. Burp Param Miner's 'Bulk scan > Web cache deception' and the WCD extension wordlist automate the same sweep.Extension sweep — find the one rule that matches

Exploitation Workflow

(6)

1. Find a dynamic, authenticated, per-user page (/my-account, /api/me, /settings, dashboards, reset/verify links).

WCD only matters when the cached response contains secrets — session-tied data, API tokens, CSRF tokens, PII, password-reset tokens. Inventory every endpoint that returns user-specific content in the body before crafting deception URLs.Step 1 — locate sensitive dynamic responses

2. Append/confuse with a static suffix and prove origin still serves the dynamic body.

Using YOUR session, request /my-account/foo.css (and delimiter variants). Confirm via no-store that the origin returns the personal page despite the .css suffix. No origin tolerance = no deception; move to the next path or delimiter.Step 2 — confirm origin path-mapping tolerance

3. Confirm the response is stored: same request twice, watch MISS→HIT and rising Age.

Send the crafted authenticated request, then immediately resend. If Cache-Control allowed storage (or the static-rule overrode a private/no-store directive) you will see a cache HIT. This is the deception working — your private page is now in a shared cache.Step 3 — verify the personal page got cached

4. Read it back with NO authentication and capture the leaked data.

From a clean client (no cookies, separate browser/incognito, or curl with no headers) request the identical URL. Retrieving the victim's body unauthenticated is the proof-of-concept. Screenshot both the authenticated store and the anonymous read for the report.Step 4 — unauthenticated retrieval = impact

5. Deliver: lure the victim to /victim-page/<random>.css, then race the cache TTL.

In a real attack the attacker picks the crafted URL, gets the victim (already logged in) to load it once (link, img tag, redirect), caching THEIR data; then fetches the same URL within the cache TTL to harvest it. Document the lure + TTL window as the realistic exploit chain.Step 5 — victim-triggered caching, attacker retrieval

6. Escalate: chain a leaked CSRF/session/reset token into account takeover.

A cached page or API response containing a CSRF token, bearer token, or password-reset token converts an info leak into full ATO. Note the downstream attack the leaked value enables — that is what moves WCD from Medium to High/Critical severity.Step 6 — token leak → account takeover

Cache & Stack Behavior Notes

(6)

Cloudflare: caches by extension regardless of Cache-Control (default static-asset list).

Cloudflare's default 'Cache Everything'-style behavior and its built-in static extension list (.css .js .jpg .png .ico .woff2 + many more) will cache by extension even when the origin sends Cache-Control: private. This is the most commonly exploited WCD configuration in the wild.Default extension list overrides private directives

Akamai: caches by path/extension via rules; ;matrix and %2f handling differ from origin.

Akamai cache rules frequently key on path patterns and extensions. Its delimiter normalization (semicolon path params, encoded slashes) often diverges from the origin app server, which is exactly the discrepancy WCD needs. Test ;foo.css and %2f variants here.Rule-based caching + delimiter divergence

Origin: Spring/Tomcat strip ;jsessionid and matrix params → /my-account;foo.css = /my-account.

Java stacks historically strip path parameters (the ;jsessionid legacy). That means /my-account;anything.css routes to /my-account at the origin while the cache sees a .css file — a near-textbook deception primitive on Spring/Tomcat targets.Java matrix-param stripping is a built-in vector

Origin: many frameworks ignore trailing path segments → /my-account/foo.css = /my-account.

Flask/Django/Express/Rails routers and several reverse proxies treat unmatched trailing segments loosely or 404 softly while still rendering the parent route. Confirm by diffing the body of /my-account vs /my-account/foo.css with your session attached.Loose trailing-segment routing at origin

Vary header: a narrow/absent Vary widens the deception blast radius.

If the cached response does not Vary on Cookie/Authorization, the cache cannot distinguish the victim's authenticated response from an anonymous request — so it serves the stored personal page to everyone. Read Vary to gauge exploitability and impact.Missing Vary: Cookie = shared private content

TTL & purge: short s-maxage shrinks the window; check Age vs s-maxage.

Exploitation is bounded by the cache TTL — compare the response Age against s-maxage/max-age to compute how long the leaked page stays retrievable. Short TTLs reduce severity; long static-asset TTLs (often days) make WCD far more dangerous.Static-asset TTLs are long — high impact window

Defenses & Detection

(6)

Cache-Control: no-store, private on every authenticated/dynamic response.

The primary fix: dynamic, user-specific responses must explicitly forbid caching. Note that on some CDNs (Cloudflare 'cache everything' / static-extension rules) origin directives can be overridden — so this must be paired with CDN-side rules, not relied on alone.Necessary but not always sufficient on its own

Configure the CDN to cache ONLY by content-type / explicit allowlist, not by extension.

Set the cache to store a response only when the ORIGIN's Content-Type is genuinely static (text/css, image/*) and matches the requested extension, instead of guessing from the URL suffix. This kills extension-abuse WCD at its root.Content-type validation defeats suffix tricks

Make cache and origin agree on URL normalization (slash, semicolon, dot, %xx).

The whole class depends on cache↔origin parsing discrepancies. Enforce identical handling of delimiters, encoded characters, matrix params, and traversal on both layers — disable matrix-param stripping or reject ambiguous paths with a 400.Eliminate the parser discrepancy entirely

Reject requests where the extension's content-type ≠ the response content-type.

A defensive cache/WAF rule: if a request ends in .css but the origin returns text/html, do not cache and optionally block. This single invariant prevents authenticated HTML/JSON from being stored under a static key.Extension/content-type mismatch = do-not-cache

Detection: alert on cache HITs for paths under authenticated route prefixes.

Instrument the CDN/log pipeline to flag cache HITs whose path begins with /account, /api/me, /settings, etc. A static asset under an authenticated prefix is a strong WCD indicator. Combine with monitoring for unusual extensions on dynamic routes.Blue-team signal: cached auth-prefixed paths

Strip/normalize trailing path segments and matrix params at the edge before routing.

Have the edge canonicalize the URL (drop ;params, collapse traversal, reject control bytes) BEFORE both the cache key is computed and the origin routes — so cache and origin operate on one agreed canonical form. Removes the gap WCD exploits.Single canonicalization point at the edge

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

IDOR Cheat Sheet HTTP Request Smuggling Cheat Sheet Web Cache Poisoning Cheat Sheet Session & Cookie Attacks Cheat Sheet

Frequently asked questions

What is the Web Cache Deception Cheat Sheet?+

It's a quick-reference collection of 37 Cache Deception payloads for testing Web Cache Deception vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these Cache Deception payloads?+

Copy any payload straight into your authorized test, or use the HTTP Header Analyzer to apply them interactively. Only test systems you have explicit permission to assess.

Are these Cache Deception payloads free to use?+

Yes — this cheat sheet and all Cache Deception payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the Web Cache Deception Cheat Sheet?+

How do I use these Cache Deception payloads?+

Copy any payload straight into your authorized test, or use the HTTP Header Analyzer to apply them interactively. Only test systems you have explicit permission to assess.

Are these Cache Deception payloads free to use?+

Yes — this cheat sheet and all Cache Deception payloads are completely free, with no account required. Everything runs in your browser.

Web Cache Deception Cheat Sheet

Static-Extension Abuse

Path-Parameter & Delimiter Confusion

Discovery & Cache-Rule Probing

Exploitation Workflow

Cache & Stack Behavior Notes

Defenses & Detection

Related Tools

Related Cheat Sheets

Frequently asked questions

Web Cache Deception Cheat Sheet

Static-Extension Abuse

Path-Parameter & Delimiter Confusion

Discovery & Cache-Rule Probing

Exploitation Workflow

Cache & Stack Behavior Notes

Defenses & Detection

Related Tools

Related Cheat Sheets

Frequently asked questions