Set cache policy for private account responses
Separate public assets from private responses. Verify browser and shared-cache behavior with two synthetic accounts and explicit storage decisions.
A cache policy should describe the response's data, not merely its route extension. A JSON endpoint can contain public reference data or private account records. An HTML page can be a static shell or include a user's billing details. Classify those responses before assigning headers.
MDN distinguishes private, no-cache, and no-store. In particular, no-cache requires validation before reuse; it is not a prohibition on storage. Select the directive that matches the actual data-handling requirement.
Write a response-class policy
Trace where responses can be cached: browser HTTP cache, service worker, reverse proxy, CDN, and application cache. A response header does not automatically govern every custom storage layer. Assign each layer an owner.
| Response class | Intended reuse | Evidence to collect |
|---|---|---|
| Versioned public asset | Shared reuse allowed | Public bytes and immutable identity |
| Personalized account HTML | No shared reuse | Edge behavior for two accounts |
| Sensitive recovery response | No storage where supported | Delivered policy and client behavior |
| Public reference API | Defined shared lifetime | No identity-dependent fields |
Document why a response is in its class. A later feature that adds a user name to a previously public payload must trigger a policy review.
Test with distinct synthetic identities
Request the same controlled route as account A, then account B, through the normal edge path. Use unmistakably different synthetic record labels. Check the body, cache-status evidence where available, and relevant response headers. Repeat after logout and after a permission change.
Do not use real customer records to detect cross-account reuse. Also avoid treating a single cache miss as proof of safety. Repeat the sequence within the expected cache lifetime and inspect the configured cache key and bypass rules.
Check storage beyond HTTP
Inspect service-worker handlers, client query caches, and persisted application state. Define when identity-bound state is cleared and whether switching accounts can reveal stale content before the next network response. Record these checks separately from CDN behavior.
A new no-store header does not retroactively remove every earlier stored copy. Plan invalidation or version changes for previously cached private content where the platform supports them. Keep the change record precise: route class, delivered policy, tested cache layers, and remaining limitations. Close the issue when the relevant storage and reuse paths follow the intended policy, not when a header checker displays a passing label.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.
Sources
- MDN: Cache-Control headerAccessed