キャッシュポイズニングとキャッシュレイヤーの防御

Web cache poisoning tricks a cache into storing a malicious response that is then served to other users. The attacker manipulates an input that influences the response but is not part of the cache key.

• Attacker sends a crafted request
• Origin reflects attacker input into the response
• Cache stores it and serves it to everyone

The root cause is an unkeyed input: a header or parameter that changes the response but is excluded from the cache key. If an attacker controls it, they poison the shared entry.

Imagine the origin reflects X-Forwarded-Host into a generated URL but the cache ignores that header. An attacker sets it to their domain, and the cached page now points everyone at attacker resources.

The primary defense is to include every input that affects the response in the cache key, or to strip dangerous headers before caching. Never reflect untrusted headers into cached output.

Cache deception tricks the cache into storing private data under a public-looking URL. An attacker appends a fake static extension so the cache treats a sensitive page as a cacheable asset.

Defend by caching based on the actual Content-Type and explicit rules, not just the URL extension. Never cache responses marked private or that set authenticated cookies.

Configure the edge to drop headers an attacker should not control before they reach the origin or cache, such as forwarded-host style headers unless explicitly trusted.

If the origin must echo a value, validate and encode it. Never build cacheable URLs or scripts directly from request headers without strict allow-lists.

Authenticated responses should generally bypass shared caches. Route logged-in requests around the public cache, or mark them private, no-store so they are never shared.

Watch for anomalies: sudden cache entries with unexpected hosts, spikes in 4xx after a deploy, or reports of users seeing foreign content. Detection lets you purge fast.

Protect the cache layer by:

• Keying on every response-affecting input
• Stripping untrusted forwarding headers
• Caching by content type, not URL extension
• Never caching private or authenticated responses
• Encoding any reflected request values

You learned how cache poisoning and cache deception attacks exploit unkeyed inputs and URL-based caching. You saw defenses: rigorous cache-key hygiene, stripping untrusted headers, caching by content type, never sharing authenticated responses, and monitoring for anomalies.