Can Your CDN Cache a Logged-In Page?
Session cookies do not automatically protect private responses. Audit Cache-Control, Vary, CDN rules, and logout behavior with two test accounts.
A user signs in and opens a dashboard. Shortly afterwards, a second user requests the same URL and sees data from the first account.
The obvious diagnosis is broken authorization. But the origin check may be correct. The defect can sit in front of it: a shared cache reused a personalized response.
The audit question is therefore: Which responses may be reused across users, and where is it technically guaranteed that private responses are excluded?
A session cookie is not a cache prohibition
RFC 9111 explicitly notes that Set-Cookie does not inherently prevent an otherwise cacheable response from being cached. Servers that need to control storage are expected to send appropriate Cache-Control directives.
This matters especially for cookie-based sessions. RFC 9111 defines extra shared-cache constraints for requests carrying Authorization. An ordinary session cookie does not create an equivalent automatic safety boundary.
Individual platforms can add stricter defaults. Vercel currently documents, for example, that responses containing Set-Cookie, private, no-cache, or no-store do not meet its CDN cache criteria. That is useful platform behavior, not a substitute for an explicit application policy.
private, no-cache, and no-store are different
private prevents shared caches from storing a response while still allowing a private browser cache in principle.
Despite its name, no-cache does not mean "do not store." Storage is allowed, but the response must be validated with the origin before reuse.
no-store tells private and shared caches not to store the response. OWASP recommends it for sensitive responses, particularly when information should not remain available from local cache or history after logout.
For ordinary personalized UI, private can be appropriate. For highly sensitive material, no-store is often the stronger fit.
Three red flags
1. s-maxage is global on SSR routes. s-maxage explicitly targets shared caches. Check whether performance middleware accidentally reaches login, account, checkout, or dashboard routes.
2. The response varies by cookie, but the cache key does not. RFC 9110 describes Vary as expanding the cache key. Vary: Cookie is not a universal fix: consent, analytics, and experiment cookies can create excessive variants. Keeping private pages out of shared caches is often simpler.
3. Production headers differ from source code. Edge platforms can add or override cache controls. Vercel, for example, documents separate Cache-Control, CDN-Cache-Control, and Vercel-CDN-Cache-Control layers. The delivered production response is what matters.
The test requires two accounts
One developer identity will often miss cross-user caching.
- Account A requests a personalized URL and warms the cache.
- Record response headers,
Age, cache status, and visible data. - Account B requests the exact same URL in an isolated browser context.
- Compare the responses.
- Repeat with warm and cold cache states.
Do not test HTML only. Include JSON APIs, private downloads, PDFs, exports, basket and checkout pages, GraphQL GET requests, and image or document proxies.
Test logout too: after sign-out, new requests must no longer be authorized. On sensitive pages, the Back button should not reveal confidential information from local cache.
What Website-Pflichtencheck would inspect
A cache and privacy audit examines the application, browser, CDN, and reverse proxy together:
private,no-cache,no-store,max-age, ands-maxage;Varyand real cache-key dimensions;- cookie-based and Authorization-based sessions;
- CDN and proxy overrides;
Ageand cache-status headers;- tests using two isolated accounts;
- logout and Back-button behavior;
- private downloads, exports, and API responses.
The goal is not "turn caching off." It is a clear boundary: Public responses may be reused. Private responses must never accidentally become shared content.
If nobody on the team can explain whether an authenticated route is stored by the browser, reverse proxy, or CDN, that is not merely a performance detail. It is a useful audit target.