Module 28 · Web Cache Attacks — Deception, Poisoning, Key Confusion

Last updated: May 18, 2026

Why cache attacks are different

Web applications use multiple cache layers: CDN edge cache, origin proxy cache, application cache. Each interprets URLs and headers slightly differently. The gap between interpretations is the attack surface.

Web Cache Deception

The attack:

1. Authenticated user visits https://app.com/account/details.css.
2. CDN sees “.css” suffix; caches the response as a static asset.
3. Origin sees /account/details as a path (ignores arbitrary suffix); returns the user’s account page.
4. The user’s private page is now in the CDN cache.
5. Attacker visits the same URL; CDN serves the cached page; attacker reads the victim’s account.

Defender: ensure CDN caching decisions align with the origin’s content type. Cache only based on Content-Type header from origin, not URL suffix.

Cache Poisoning

Attacker injects content into cache that subsequent users receive. Variants:

• Unkeyed input: a request header (e.g., X-Forwarded-Host) influences the response but isn’t part of the cache key. Attacker sends request with malicious header; response is cached; all subsequent victims receive the poisoned response.
• HTTP request smuggling: front-end and back-end disagree on request boundaries; attacker injects a “second” request whose response gets cached against a different key.
• Parameter cloaking: front-end and back-end disagree on URL parameter parsing.

The James Kettle research

James Kettle (PortSwigger) has documented cache attack patterns extensively. Key reading: “Practical Web Cache Poisoning” (2018) and follow-ups. The techniques scale to modern CDN deployments.

Cache key confusion

The cache key determines what makes two responses “the same.” If the key omits a relevant input, responses across different inputs may be served interchangeably.

# Cache key = path only
Request: GET /api/me
Cookie: session=abc123
Response: { "email": "[email protected]" }
# CDN caches this with key "/api/me"

Request: GET /api/me
Cookie: session=def456
# CDN serves the cached [email protected] response to user with session def456

# Fix: include session-identifying header in cache key,
# OR mark response as private (Cache-Control: private, no-store)

The Cloudflare-specific patterns

Cloudflare’s caching is rule-driven. Common misconfigurations:

• “Cache Everything” rule applied to a path that should be dynamic.
• Cache-Control headers from origin overridden by Cloudflare rules.
• Query-string variations cached separately, blowing up cache hit ratio without security benefit.

Testing cache attacks

• Send the same URL with different cookies; observe whether responses differ — if not, caching may be leaking.
• Try unusual suffixes (.css, .js, .png) on authenticated paths.
• Inject headers like X-Forwarded-Host, X-Forwarded-For, X-Original-URL into requests; observe whether they influence the response.
• Use Param Miner (Burp extension) to discover unkeyed parameters.

Defender checklist

• Authenticated responses: Cache-Control: private, no-store. Set at origin; trust the CDN to respect.
• CDN cache rules align with content type, not URL pattern.
• Cache key includes all request inputs that influence response, including relevant headers.
• Audit cache configurations periodically; unsafe rules drift in.
• WAF rules to block requests with header injection patterns.

Common failure modes

• Authenticated pages cached publicly due to suffix-confusion.
• Unkeyed input from header lets attacker poison cache for all subsequent users.
• HTTP request smuggling allows cache-key confusion.
• CDN configuration “Cache Everything” applied without understanding origin behaviour.

Key takeaways

• Cache attacks exploit gaps between CDN, proxy, origin interpretations.
• Web Cache Deception: URL suffix that CDN treats as static but origin treats as dynamic.
• Cache Poisoning: unkeyed input shapes response; gets cached for everyone.
• Cache key must include every input that influences response.
• Authenticated responses: Cache-Control: private, no-store.

Related engagement → How we ran a web app pentest for a leading Indian fintech