New CS proposal: Web Cache Security

What is the proposed Cheat Sheet about?

Web Cache Security Cheat Sheet would provide developers and operators with practical, vendor-neutral guidance on using HTTP and application-level caches safely. It would focus on preventing data exposure and response integrity issues. The cheat sheet would cover private browser caches, shared reverse proxies and CDNs, as well as in-memory and distributed application caches.

What security issues are commonly encountered related to this area?

• Sensitive, authenticated, or personalized responses being stored in a shared cache and then served to another user.
• Assuming that authentication cookies or a Set-Cookie response header automatically make a response private.
• Confusing Cache-Control: no-cache, which allows caching but requires revalidation, with no-store, which prevents storage.
• Web cache poisoning, where an attacker-controlled header, query parameter, host value, path component, or other input that is not part of the cache key changes a cached response.
• Web cache deception, where a dynamic or authenticated endpoint accepts a static-looking path or file extension and the personalized response gets cached.
• Cache-key collisions caused by inconsistent URL normalization, query-string handling, forwarded headers, or routing between the cache and the origin.
• Cross-user or cross-tenant data leakage when application cache keys do not include tenant identity or other authorization-related context.
• Cache hits bypassing object-level or tenant-level authorization checks.
• Cached content remaining accessible even after permissions, account status, or the underlying resource has changed.
• Secrets or session identifiers being exposed through cache keys, logs, purge URLs, statistics, or administrative interfaces.
• CDN, reverse-proxy, or framework rules overriding safer origin cache policies based on paths, file extensions, or response status.
• Incident response that only purges a poisoned cache entry without fixing the cache key or origin behavior that caused the issue.

What is the objective of the Cheat Sheet?

The objective is to provide a concise, architecture-first reference for implementation and security reviews. It would help developers decide what can be safely cached and which request inputs must be considered when selecting a cache entry.

What other resources exist in this area?

• RFC 9111: HTTP Caching defines HTTP cache storage, reuse, cache keys, validation, authenticated-response behavior, and security considerations.
• MDN: HTTP Caching and MDN: Vary provide developer-oriented explanations of private and shared caches, response directives, heuristic caching, and representation selection.
• OWASP: Cache Poisoning describes how a harmful stored response can affect other users of a shared cache.
• Cloudflare: Avoid Web Cache Poisoning, Cache Deception Armor, and Cache Keys document practical intermediary-layer risks and mitigations.
• The OWASP HTTP Headers, Session Management, Authorization, and Multi-Tenant Security cheat sheets cover adjacent controls but not the complete cache lifecycle and cross-layer trust boundary.