testing-web-cache-attacks

name	testing-web-cache-attacks
description	Test how a caching layer between users and an application can be turned against it: cache poisoning (getting a harmful response stored and served to other users) and cache deception (tricking the cache into storing a victim's private response where the attacker can read it). Covers finding the cache key and unkeyed inputs, identifying cacheable responses, poisoning through unkeyed headers, and deceiving path-based caching into storing authenticated content. Use when reviewing a CDN, a reverse proxy, or any shared HTTP cache in front of an app.
license	MIT

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.