Skip to content

Archive

HTTP Caching

2 articles
Cybersecurity 13 Sep 2026 8 min read

Cache Keys Define a Security Boundary at Shared Proxies

A reverse proxy can receive two HTTP requests that look equivalent to its cache while the application behind it treats them as different. That disagreement is more than a performance bug. If an attacker can place a response generated from one request variant into a shared cache entry used by other clients, a request that originally affected one connection can acquire a much larger audience. This is the core security tension in web cache poisoning. The cache key defines which requests are considered interchangeable. The origin application defines which request properties can alter a response. Security depends on those two models staying aligned across proxies, frameworks, routing rules, and application code.

Cybersecurity 11 Sep 2026 9 min read

Design Shared Cache Keys Around Response Variance

Shared HTTP caches can reduce latency and origin load, but they also introduce a security boundary. A cache stores a response produced for one request and may later serve that response to another request. That reuse is correct only when both requests are equivalent for every property that can affect the response. A dangerous configuration appears when an origin varies its response on a request property that the shared cache does not include in cache selection. An attacker can send a crafted request, cause the origin to generate attacker-influenced content, and leave that content stored under a key that ordinary visitors also use.