no-store

Overview

The term no-store refers to a directive used in HTTP headers and cache control mechanisms to prevent the storage of resources in any form of cache, including browser caches, proxy caches, or CDN caches. It is a critical component in secure and controlled data delivery, particularly in environments where sensitive information must not be cached or persisted in intermediate systems.

In the context of web development, no-store is most commonly seen in the Cache-Control header, where it explicitly signals to all caching layers that a resource must not be stored under any circumstances. It is used in both client-side and server-side contexts, often in combination with other cache directives to fine-tune caching behavior.

no-store developer glossary illustration

Why It Matters

For developers, no-store is essential when dealing with sensitive data, dynamic content, or user-specific resources. If such content is cached, it can be accessed by unauthorized users, potentially leading to data exposure or session hijacking. For example, a login page or a user profile page should never be cached, as it may contain personal or confidential information.

Additionally, no-store ensures that the latest version of a resource is always fetched, which is crucial for applications that rely on real-time updates or frequent content changes. Without this directive, users might see stale content, leading to a degraded experience or incorrect data being displayed.

How It Works

The no-store directive is part of the HTTP Cache-Control header, which is used to specify caching mechanisms in both requests and responses. When applied to a response, it instructs all caching systems to completely avoid storing the response body, headers, or any part of it.

The directive is case-insensitive and must be included in the Cache-Control header of an HTTP response.
It overrides other cache directives such as max-age, public, or private when present.
It is not a replacement for other security measures but is a critical part of a layered approach to content protection.
It can be used in conjunction with no-cache, which allows storage but requires revalidation.
It is supported across all modern browsers and HTTP caching systems, including proxies and CDNs.

Quick Reference

Item	Purpose	Notes
Cache-Control: no-store	Prevents caching of the response	Effective for all cache layers
Response header	Used in HTTP responses	Must be set by the server
Client behavior	Client must not cache the response	Applies to browser and proxy caches
Override behavior	Overrides other cache directives	Has highest precedence
Browser support	Universal support in modern browsers	Used in HTTP/1.1 and HTTP/2

Basic Example

The following example demonstrates how to apply the no-store directive in an HTTP response header using a server-side script. This is a minimal example showing how to send the header directly.

HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: text/html

In this example, the Cache-Control: no-store header ensures that the browser and any intermediaries will not cache the response. The Content-Type header is included for completeness but is unrelated to the no-store directive.

Production Example

In a production environment, developers often combine no-store with other directives for more robust caching control. The following example shows how a backend service might configure headers for sensitive pages.

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: application/json

This configuration ensures that the response is not cached in any way, and that it is revalidated on every request. The Pragma: no-cache and Expires: 0 headers provide backward compatibility with older HTTP versions.

Common Mistakes

Applying no-store to static assets like images or CSS that do not contain sensitive data, which can unnecessarily increase bandwidth usage and reduce performance.
Using no-store without other cache directives, leading to inconsistent behavior across different caching layers.
Confusing no-store with no-cache, which results in improper caching control and potential performance issues.
Assuming that no-store is sufficient for all security requirements, ignoring other aspects like authentication or encryption.
Forgetting to set the header on all relevant resources, especially dynamic or user-specific pages, which leaves some content vulnerable to caching.

Security And Production Notes

no-store is not a substitute for encryption or authentication; it only controls caching behavior.
It should be used consistently across all sensitive resources, including login pages, user dashboards, and API responses.
When combined with no-cache, it ensures that the resource is never served from cache without revalidation.
Implementing no-store correctly helps avoid data leakage through cache poisoning or unauthorized access.
It is crucial to test the behavior in both browser and proxy environments to ensure compliance with caching policies.

Related Concepts

Several related concepts are important to understand when working with no-store. These include:

Cache-Control: The HTTP header that defines caching behavior for resources.
no-cache: A directive that allows storage but requires revalidation before reuse.
max-age: A directive that sets the maximum time a resource can be cached.
private: A directive that restricts caching to the user's browser and not shared across users.
ETag: An HTTP header used for validating cached resources and enabling conditional requests.