Cache-Control: private, no-cache and no-store

Separate storing and reusing

no-cache permits storage but requires successful validation before reuse. no-store directs caches not to store the response.

The names are easy to confuse. Choose based on whether storage itself is allowed or only stale reuse is prohibited.

Cache-Control: no-cache
May store; must validate before reuse.
Cache-Control: no-store
Do not store.

Private does not mean no storage

private prevents shared caches from storing the response under its rules; a private browser cache may still store it.

For user-specific content, decide whether browser storage is acceptable as well as whether CDN storage is acceptable.

Keep freshness separate from identity

max-age sets freshness lifetime and does not make a representation safe to share across users. Shared caching also depends on request and response rules.

Use validators for revalidation and Vary for relevant request-header selection. Do not use long freshness as a substitute for correct cache keys.

Cache-Control: private, max-age=60
A private cache can reuse while fresh; shared storage is restricted.

Inspect more than one cache layer

Browser, service worker, reverse proxy and CDN layers can apply different behavior. A visible header is only part of the deployed configuration.

Test an authorized resource with fresh, revalidated and changed versions. no-store is not a command to erase every previously stored copy.