Cache-Control is an HTTP header that tells browsers, proxies and other intermediaries how to store and reuse a response. It can set whether content is cacheable, who may cache it, how long it stays fresh, and when it must be revalidated, which affects performance and the risk of serving stale or sensitive data.
How Cache-Control Shapes Caching Behaviour
Cache-Control is the response header that tells browsers, proxies, and CDNs whether a response may be stored, how it may be reused, and when it must be revalidated. Those directives determine whether users get faster repeat loads or a fresh fetch from origin.
At its core, the header is about cache policy. It can allow caching, prevent storage altogether, limit reuse to private caches, or define freshness with directives such as max-age and must-revalidate. That makes it one of the most important controls for HTTP performance and content correctness.
Why Cache-Control Matters for Sensitive and Dynamic Content
Cache-Control becomes especially important when responses contain personalised data, session-specific content, or rapidly changing information. If shared intermediaries store the wrong response, one user may receive data meant for another, or a browser may continue showing a stale page after the underlying state has changed.
This is why cache policy must match the sensitivity and volatility of the content. Public assets, static images, and versioned scripts often benefit from long-lived caching, while authenticated pages, account data, and transaction results usually need tighter controls such as private or no-store handling. For broader header hardening and adjacent controls, see the Security Headers Guide.
Cache Keys, Revalidation, and Intermediary Behaviour
Cache-Control does not act alone. It works with request and response headers that influence cache keys, conditional requests, and reuse decisions. A response may be cacheable in principle, but still be revalidated before reuse if the freshness lifetime has expired or if the origin requires confirmation.
Intermediaries can also behave differently depending on deployment path, edge configuration, and vendor defaults. That is why cache policy should be reviewed alongside path handling, origin routing, and response variation rules. If those pieces are inconsistent, caching can become unpredictable even when the header looks correct.
Common Failure Modes and Safe Usage Patterns
The most common mistakes are over-broad caching, missing privacy constraints, and assuming that a browser-only setting will also protect intermediaries. A response that should never be reused may still be stored if the cache policy is incomplete, and a response that varies by user or location may be shared if the cache key is not designed carefully.
Safe usage usually means aligning the directive with the data classification of the response, not just with performance goals. That includes deciding when content is public, when it is private to a single user, and when it must not be stored at all. The practical discipline is to make caching explicit instead of relying on default intermediary behaviour. For attack patterns that abuse cache behaviour, the Web Cache Poisoning and Cache Deception Guide is a useful companion reference.
Risk and Threat Considerations
Misused cache directives can expose sensitive data, preserve stale security state, or let an attacker influence what future users receive from a shared cache. The risk is highest when dynamic content is cached as if it were public, or when an intermediary stores a response without understanding how the application varies content.
Failure mechanism: A cache stores a response that should have been private, non-cacheable, or tightly revalidated, then reuses that response across users or after the origin state has changed.
Impact: Users may see stale or cross-user content, sensitive information can leak through shared intermediaries, and poisoned cache entries can amplify the effect of a single malicious request.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | Cache reuse can affect response integrity and user session handling. |
| SC-28 — Protection of Information at Rest | Caching stores response data in intermediary storage where sensitivity matters. | |
| Recommendation — Apply SC-23 to prevent reused responses from undermining session integrity. Use SC-28 to limit how sensitive response data is retained in cache storage. | ||
| OWASP ASVS | V14 — Data Protection | Cache policy directly affects whether sensitive data is stored or reused by clients and intermediaries. |
| V3 — Web Frontend Security | Browser caching behaviour is part of web frontend response handling and privacy. | |
| V16 — Security Logging and Error Handling | Cache failures can hide or prolong incorrect response behaviour that needs detection. | |
| Recommendation — Apply V14 to ensure sensitive responses are not cached beyond their intended exposure. Use V3 to align browser-side caching with the page's privacy requirements. Use V16 to log and review cache-related response anomalies. | ||
Practitioner Guidance
What to watch for: Review Cache-Control together with the actual response body, authentication state, and cache key design, not as an isolated header. The right policy depends on whether the content is public, personalised, or stateful, and on whether any intermediary can store it outside the browser.
Governance implication: Treat cache directives as part of response security design, not just performance tuning. Teams that own application responses, CDN configuration, and security reviews should agree on when private, no-store, or revalidation-heavy behaviour is required.