Cybersecurity glossary
What is Cache-Control?
Learn what the Cache-Control HTTP header does, how directives like max-age, no-store, and private shape browser and CDN caching, and how to avoid leaking sensitive responses.
Definition
Cache-Control is an HTTP header that tells browsers, proxies, and CDNs whether a response may be stored, how long it may be reused, and under which privacy constraints, using directives such as max-age, no-store, private, and must-revalidate.
Why Cache-Control matters
Every HTML page, API payload, and static asset sits on a spectrum between “reuse aggressively” and “never store.” Cache-Control is the primary way origins express that intent to browsers, reverse proxies, and CDNs.
Get it right and sites feel fast while personal data stays out of shared caches. Get it wrong and you either hammer origins with avoidable traffic or accidentally let a CDN serve one user’s private page to another visitor.
How Cache-Control works
Servers attach Cache-Control on responses. Compliant caches interpret directives to decide store eligibility, freshness lifetime, and whether revalidation is required before reuse.
Origin emits directives
The response includes Cache-Control values that encode freshness and privacy rules.
Cache evaluates store rules
Shared and private caches check whether storage is allowed (for example no-store or private).
Freshness window applies
Directives such as max-age define how long a stored response can be served without revalidation.
Reuse or revalidate
When fresh, caches may reuse the body. When stale, they revalidate or fetch a new representation.
Downstream respects intent
Browsers, CDNs, and proxies should honor the strictest applicable constraints for that response.
Common directives
max-age
Freshness lifetime in seconds for the response in compliant caches.
no-store
Do not store the response in any cache. Strong default for sensitive HTML and tokens.
no-cache
May store, but must revalidate with the origin before reuse.
private
Only a private (usually browser) cache may store the response—not shared CDNs.
public
Allows shared caches to store the response when other rules permit.
must-revalidate
Once stale, caches must not serve the response without successful revalidation.
Choosing directives by content type
| Content | Typical Cache-Control | Why |
|---|---|---|
| Hashed static JS/CSS | public, max-age=long, immutable | URL changes on deploy; safe to cache hard |
| Public marketing HTML | public, short max-age or SWR pattern | Speed with controlled freshness |
| Authenticated app HTML | private, no-store (or no-cache) | Avoid shared-cache leakage of sessions |
| API with user data | private, no-store | Personal JSON must not hit CDNs |
| Error pages with secrets | no-store | Debug bodies often include sensitive context |
Security checklist
- Default authenticated and personalized responses to no-store or private + revalidate.
- Never mark cookie-authenticated HTML as public on a shared CDN.
- Use long max-age only when the URL is content-addressed (hash in filename) or otherwise immutable.
- Audit intermediary overrides; some CDNs ignore or transform Cache-Control unless configured.
- Pair caching rules with correct Vary headers when responses differ by Authorization, Cookie, or Accept.
- Treat no-cache as revalidate-before-reuse, not as no-store.
- Review Set-Cookie responses carefully; caches must not store personalized Set-Cookie pages as shared.
- Test with real CDN behavior, not only local browser DevTools.
Limits and pitfalls
Cache-Control is only as strong as every hop that claims to honor HTTP caching. Misconfigured CDNs, stale edge rules, or application frameworks that emit conflicting Expires / Pragma headers can undermine intent.
Another frequent mistake is using no-cache when the team meant no-store. The names sound similar; the storage outcomes are not.
The practical takeaway
Cache-Control tells the web’s caches whether a response may be stored, how long it stays fresh, and whether shared infrastructure may hold it. Treat it as a security control for personalized content and a performance control for immutable assets.
Write directives deliberately per route class, verify them at the CDN, and assume a wrong public on an authenticated page is an incident waiting to happen.
Related security terms
ETag
Validators used with revalidation when Cache-Control allows reuse.
Cache Revalidation
How clients confirm a stored response is still fresh.
Web Cache Poisoning
Attacks that abuse shared caches when caching rules are too permissive.
HTTPS
Transport security that pairs with careful caching of authenticated pages.
Frequently asked questions
What is Cache-Control in simple terms?
It is a set of instructions on an HTTP response that say whether the content can be saved for later and for how long. Browsers and CDNs read those instructions before deciding to store or reuse a page or file.
What does no-store mean?
no-store asks caches not to store the response at all. It is commonly used for authenticated HTML, personal data, and one-time tokens where reuse would be unsafe.
What is the difference between private and public?
private means only a single-user cache (typically the browser) may store the response. public allows shared caches such as CDNs to store it when other freshness rules also allow.
Does Cache-Control replace HTTPS?
No. Cache-Control controls storage and reuse. HTTPS protects data in transit. Sensitive pages often need both HTTPS and strict Cache-Control.
What does max-age do?
max-age sets how many seconds a response may be considered fresh without contacting the origin. After that period, caches usually revalidate or refetch.
Can Cache-Control appear on requests?
Yes. Clients can send Cache-Control on requests (for example no-cache) to influence how intermediaries handle the request, but response directives are what most teams configure for pages and APIs.
References
Explore authoritative guidance and frameworks related to cache-control.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.