testing-web-cache-attacks

# Testing web cache attacks: the bug is the key, not the app A shared cache trades correctness for speed by serving one stored response to many users, and that sharing is the vulnerability. If an attacker can influence what gets stored (poisoning), everyone downstream receives their payload; if an attacker can make the cache store someone else's private response under a key the attacker controls (deception), they read data that was never theirs. Both live in the gap between what the cache keys on and what actually determines the response. ## When to use - You are reviewing a CDN, a reverse proxy, or any shared HTTP cache in front of an app. - Responses that depend on headers or user identity are served through a cache. - You are assessing whether authenticated content can be cached and re-served. ## Scope check Test caches and apps you own or are authorized to test. Use benign markers and your own accounts; do not poison responses served to real users or read real users' data. If you can't name the authorization, stop. ## The loop 1. **Map the cache and its key.** Identify the caching layer in front of the app and determine the cache key: which parts of the request (path, query, some headers) decide whether two requests share a stored response. Everything the response depends on but the key ignores is an unkeyed input, and unkeyed inputs are where both attacks live. 2. **Find what is cacheable.** Determine which responses the cache stores and for how ...