Resources · 63
HTTP caching: protect personalized responses
Separate shared, private and application caches, inspect keys, revalidation and invalidation after access-right changes.
· 2 min
What this guide helps achieve
- Inventory layers
- Choose retention
- Inspect keys
- Exercise revalidation and change
Quick check
- Does no-cache mean nothing is retained?
- Does Vary protect access rights?
- Should every API be cached?
Step-by-step method
- 01
Inventory layers
List browser, CDN, proxy, service worker and application caches. Classify public and personalized responses. An HTTP policy does not automatically describe caching implemented in code.
Deliverable: layers and owners diagram.
- 02
Choose retention
RFC 9111 distinguishes directives: no-cache requires validation before reuse, no-store prohibits the relevant HTTP storage, and unqualified private excludes shared storage. None alone guarantees system confidentiality.
Deliverable: retention policy per response.
- 03
Inspect keys
Check method, URI and dimensions changing a representation. Vary concerns request fields; it is not authorisation. Seek omitted language, format negotiation and account context in application layers.
Deliverable: keys and separation tests.
- 04
Exercise revalidation and change
Test fresh and stale responses, data updates and revoked rights. Inspect ETag, conditional validation and origin-unavailable behaviour. A formerly correct response may become sensitive after revocation.
Deliverable: before-and-after traces.
- 05
Replay with two accounts
Use fictional identities and markers. Alternate requests to the same URI with warm and cold caches. Check logout, direct links and logging without recording real tokens.
Deliverable: negative tests and invalidation strategy.
Reusable worksheet
Complete with your authorised observations. These fields are a working template, not observed results.
| Field | Information to record |
|---|---|
| Response | Public or personalized; dimensions |
| Layer | Cache, owner and key |
| Policy | Retention, freshness and validation |
| Trial | Fictional account, change and observation |
Worked example
Illustrative situation
Fictional example: a CDN reuses a profile response at the same URI for two test accounts.
Decision and expected evidence
The scenario detects leakage, examines policy and keys, then replays after correction and access revocation.
Distinguish the mechanisms
| Mechanism | Purpose | Check or limitation |
|---|---|---|
| no-cache | Permit storage with required validation | Do not read it as no storage |
| Unqualified private | Exclude shared caching | Do not read it as a confidentiality guarantee |
| no-store | Prevent the relevant HTTP storage | Check application caches and history separately |
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Account separation | No marker from another account | Inspect body, links and metadata |
| Age and validation | Reuse consistent with policy | Test expiry and unavailable origin |
| Invalidation delay | Time until corrected representation | Name each layer still stale |
Common pitfalls
- Do not read it as no storage
- Do not read it as a confidentiality guarantee
- Check application caches and history separately
Frequently asked questions
Does no-cache mean nothing is retained?
No. It requires validation before reuse; it does not prohibit storage as no-store does.
Does Vary protect access rights?
No. It participates in representation selection; authorisation remains separate.
Should every API be cached?
No. Benefits depend on cost, freshness and risk. Sensitive responses may justify avoiding shared caches.
Official references
References consulted on 2 October 2026. The method and worksheet propose checks to adapt to your context; they do not constitute certification.
Continue exploring
Related analysis
