Cache-Control: private directs shared caches not to store a response for reuse by multiple users. It is used for content that may be cached only in a browser or similarly limited context. For sensitive application output, it helps reduce the chance that one user receives another user’s data.
Expanded Definition
Cache-Control: private is an HTTP response directive that tells shared intermediaries such as proxy caches, CDN edges, and gateway layers not to reuse a response for multiple users. It allows browser-side caching while limiting storage in shared cache layers, which makes it useful for personalised pages, account views, and other responses that may contain user-specific data. The directive is part of HTTP caching behaviour rather than an access control mechanism, so it should be treated as a data handling signal, not a security boundary. For implementation context, teams often align it with broader web privacy and response handling guidance, including NIST SP 800-53 Rev 5 Security and Privacy Controls when designing controls around data exposure and response protection.
Definitions vary across vendors on how aggressively edge platforms interpret cache directives, especially when multiple headers interact, such as Cache-Control, Vary, and Expires. The practical meaning is consistent, but enforcement can differ across browsers, reverse proxies, and application delivery networks, so validation is required in the actual delivery path. The most common misapplication is assuming Cache-Control: private prevents disclosure of sensitive content, which occurs when developers rely on it alone while the response is still accessible through logging, browser back buttons, screenshots, or incorrectly configured downstream caches.
Examples and Use Cases
Implementing Cache-Control: private rigorously often introduces a small performance tradeoff, requiring organisations to weigh safer handling of user-specific responses against the benefit of faster reuse across shared infrastructure.
- Account dashboards that show balances, tickets, or profile data can be cached in the browser without being stored for other users at a shared cache layer.
- Authenticated API responses can include private caching directives so that session-specific content is handled locally, not by a CDN intended for public reuse.
- Healthcare or benefits portals can reduce accidental cross-user exposure by marking personalised pages as private while still allowing short-lived browser caching.
- Applications that combine private content with public assets can pair private directives with HTTP caching behaviour guidance and careful header testing to ensure the right content is cached in the right place.
- Teams running security reviews may use private caching alongside response headers such as no-store for especially sensitive outputs where even browser retention is undesirable.
Why It Matters for Security Teams
Security teams care about Cache-Control: private because caching mistakes are a common way that user data crosses trust boundaries without any direct authentication failure. The directive helps reduce exposure in shared delivery layers, but it does not replace authorization checks, session controls, or data minimisation. That distinction matters in modern environments where browsers, reverse proxies, service meshes, and edge platforms can all influence how a response is stored and replayed. For governance and web hardening, teams often pair it with related controls from OWASP guidance and with cache-aware architecture reviews to verify that personal, regulated, or session-bound output is not reused outside its intended context. In identity-heavy applications, the risk is especially acute when account views, authentication prompts, or delegated access screens expose data that should remain bound to a single user session. Organisations typically encounter the consequences only after a shared cache serves one user another person’s data, at which point Cache-Control: private becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | Protects data-in-transit and data handling to reduce unintended exposure from cached responses. |
| NIST SP 800-53 Rev 5 | SC-5 | Defines denial of service protection, which intersects with careful cache use and response handling. |
| OWASP Non-Human Identity Top 10 | Relevant where agent or identity-driven sessions return user-specific outputs that must not be shared. | |
| NIST SP 800-63 | IAL2 | Identity proofing and session-bound identity data increase the impact of improper cached response reuse. |
Treat private caching as part of data protection design and verify responses do not leak across trust boundaries.
