Cache-Control No-Store

What Cache-Control No-Store Does in Practice

Cache-Control: no-store instructs browsers and intermediary caches not to retain the response at all, which is why it is used for pages that carry tokens, session material, personal data, or other content that should not persist after use.

It is a response-handling control, not an access-control decision. The directive reduces the chance that sensitive material is left behind on a shared device, in a browser cache, or in an intermediary cache that another user or process could later inspect.

Where No-Store Fits in HTTP Caching

HTTP caching exists to improve performance, but not every response should be cacheable. No-store is the strongest “do not keep a copy” instruction in the cache-control family, and it is typically chosen for pages where confidentiality matters more than reuse.

The directive is often paired with other response protections, but its job is specifically to prevent storage. If a response must never be retained, no-store is more appropriate than relying on time-limited caching or browser history management alone.

For a broader view of how response headers work together, the Security Headers Guide shows how cache directives sit alongside HSTS, CSP, cookie attributes, framing controls, and related browser protections.

Why No-Store Matters for Sensitive Sessions

No-store matters when the response contains material that would be harmful if recovered after the intended session ends. That includes authenticated account pages, password reset flows, token-bearing screens, and any view that may expose personal or regulated information.

The main security value is reduction of residual exposure. Even when transport security and authentication are strong, cached response bodies can create a separate disclosure path if a browser profile is reused, a shared workstation is not fully cleared, or an intermediate component retains content longer than expected.

When evaluating response-hardening alongside broader control baselines, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control vocabulary practitioners commonly use for access control, auditability, configuration, and system integrity.

How to Use It Without Creating False Confidence

No-store is useful, but it is not a substitute for safe session design. If a page exposes sensitive data, organisations still need short-lived sessions, secure cookie handling, and careful treatment of redirects, error pages, and downloadable artifacts that may carry the same information through a different path.

It also helps to remember that caches are only one place where sensitive content can linger. Browser autofill, local storage, logging, screenshots, proxies, and copied URLs can all create separate exposure paths, so no-store should be part of a wider data-minimisation approach rather than the only safeguard.

For teams mapping this control into a formal security programme, the NIST Cybersecurity Framework 2.0 helps place response-hardening measures inside the broader identify, protect, detect, respond, and recover lifecycle.

Risk and Threat Considerations

Responses that are not marked no-store can leave sensitive material behind in places the application team does not directly control, which is especially risky on shared devices, reused profiles, and intermediaries that may persist content longer than the user expects. The concern is not only browser convenience, but accidental recovery of session material, account data, or credential-linked information after the user believes the page is gone.

Failure mechanism: A sensitive response is cached, then later retrieved from browser history, a shared workstation, an intermediate cache, or another local user context that still has access to the stored copy.

Impact: Confidential data exposure, session compromise, and secondary account abuse can follow if the cached response contains tokens, identifiers, or other sensitive material.

Practitioner Guidance

Why practitioners should care: No-store should be treated as a deliberate confidentiality decision for specific responses, not as a default setting for every page. Use it where retaining the response would create material exposure if a device, browser, or shared environment is reused.

Common misunderstanding: Many teams assume that private pages are “safe enough” once they are behind authentication. In practice, the cache decision is separate from the login decision, so the response itself still needs explicit handling when it carries sensitive material.

Practitioner takeaway: Apply no-store to responses that carry tokens, session material, or sensitive personal data, and verify that adjacent controls do not reintroduce the same information through another channel.

Related resources from NHI Mgmt Group

• Who is accountable for access continuity when an identity control plane loses its backing store?
• How should organisations implement policy-based access control when multiple business units share the same cloud data store?
• Why does the FTC Safeguards Rule make MFA a critical control for organizations that store customer financial data?
• What happens when organisations store sensitive data in SharePoint without discovery and control?