News
CDN Cache Keys vs Cache-Control for Personalized Pages
June 3, 2022
CDN cache keys vs Cache-Control for personalized pages is two different caches. Cache-Control tells browsers and shared caches whether HTTP may store the response (public, private, no-store). The CDN cache key is how the edge decides two requests are 'the same object' — often scheme, host, and path, sometimes ignoring query or cookies unless you say otherwise. If HTML varies by session cookie and the key does not include that cookie (or you marked it public), one profile's page can be stored as the anonymous URL. Vary: Cookie is the HTTP cousin; many CDNs still need an explicit cache-key rule. RoastMyOpsec compares Cache-Control to Set-Cookie on the landing HTML. It does not read CDN dashboards, does not purge keys, and does not score missing cache-key customizations.
The practical difference
Cache-Control is the origin's freshness policy. The cache key is the index. ETag is a validator, not a key. Service workers are a third cache on the device. See Cache-Control public vs private, ETag vs Cache-Control, and service workers vs Cache-Control.
A brochure with no cookies can use a boring path-only key and public caching. An account app cannot.
How to choose a keying plan
Static hashed assets: path-only key, long TTL, Cache-Control public. Personalized HTML: Cache-Control private, no-store, and do not cache at the CDN — or key on the session cookie you actually vary on, which is easy to get wrong. Prefer not caching logged-in HTML at the edge at all. Bypass cache when Set-Cookie is present unless the page is a logged-out shell.
| Layer | What it decides | Personalized HTML | Takeaway |
|---|---|---|---|
| Cache-Control | May HTTP store this? | private, no-store | Origin policy |
| CDN cache key | Which requests share a slot | Usually do not cache | Not a roast score; still hygiene |
| Vary | Which request headers change the representation | Use carefully with cookies | HTTP cousin of a key |
| Service worker | Device Cache Storage | Usually skip session bodies | Different cache |
When a custom cache key still wins
It wins for A/B cookies on otherwise public marketing HTML when you know the cookie is not a session. It never wins as a substitute for no-store on /dashboard. Missing a custom key on a brochure is healthy.
What the roast can prove
Set-Cookie plus public Cache-Control on the landing response can surface. Cache-key rules are out of scope. Confirm in the CDN dashboard. Pair with ETag if a user-agnostic validator sits on a personalized URL.
Common mistakes
The first mistake is caching / as public while a welcome-back banner is cookie-shaped.
The second mistake is including every cookie in the key and fragmenting the cache into garbage.
The third mistake is treating a roast miss on Cache-Control as proof the CDN key is safe.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Does Cache-Control private stop the CDN from caching?
- It should, if the CDN honors it. Confirm the product. Do not rely on a custom key as the only lock.
- Should brochure sites customize cache keys?
- Usually no. Path-only plus public caching for static assets is enough. Missing a custom key is not a roast F.
- Does RoastMyOpsec read CDN cache keys?
- No. It compares Cache-Control to Set-Cookie on a consented GET. Confirm keys in your CDN dashboard.