Context
Caching HTML can improve response time, but a page containing account-specific information must not become a shared response for unrelated users. The dangerous configuration is often introduced as a broad performance rule: make more paths cacheable, ignore a query string, or apply a long edge lifetime. The review must classify the response before optimizing its hit rate.
Consider an illustrative customer portal whose public pages and account pages share one hostname. A broad rule is added to improve the homepage. If the rule also makes personalized responses eligible without the intended exclusions, the application can serve the wrong cached content. A fast page is not a successful optimization if it crosses a user boundary.
Inspect effective cache behaviour
Cloudflare documents default cache eligibility, origin cache-control handling, and rules that can change behaviour. It also provides cookie-based bypass examples. The effective result depends on the configured rules and relevant product features, so do not assume a header or a default applies unchanged after an explicit override. 123
Record the route, method, origin headers, authentication indicators, applicable cache rules, and any Worker or other layer modifying the response. A single dashboard toggle cannot describe the complete cache decision when several components participate.
Classify responses by what they contain
Identify public immutable assets, anonymous public HTML, authenticated account pages, cart or checkout paths, and API responses with user data. Determine whether an apparently public page changes based on a session, locale, currency, feature flag, or authorization header. The content variation matters even when the URL remains identical.
Keep this classification connected to application code ownership. A page can become personalized after a later release without any cache rule changing. Performance review should be repeated when the response's data contract changes, not only when infrastructure settings are edited.
Make the origin's privacy intent explicit
Use appropriate application response headers for sensitive content and verify the edge respects the intended contract under the actual configuration. Review browser caching separately from shared edge caching. A response can avoid shared caching while still having a browser behaviour that needs deliberate treatment after logout.
Do not rely on a Set-Cookie header as a universal guarantee under every rule combination. Inspect the documented behaviour for the configured mode and test the resulting response. Similarly, the presence of an authentication cookie in the request should drive the intended bypass or key behaviour explicitly rather than being assumed to do so automatically.
Prefer a clear bypass for sensitive application paths
Where appropriate, exclude authenticated and sensitive routes from shared HTML caching. Keep the rule narrow enough to preserve public-page performance but broad enough to cover actual session and API paths. Match the application's real authentication indicators, including changes introduced by a framework or identity provider.
A custom cache key is not a substitute for authorization. Adding a user-related value can create high cardinality, retention concerns, and difficult invalidation. For private account content, assess whether shared edge storage is needed at all before designing a complex per-user key scheme.
Run a controlled two-user test
Use two authorized test accounts with clearly different harmless data and separate browser sessions. Request the same relevant URL as user A, user B, and an anonymous visitor. Inspect response content, cache-related headers, origin logs, and whether repeated requests follow the intended caching behaviour.
Test login, logout, session expiry, and account switching. Include query-string variants and any route rewrites the application uses. A successful test of one unique URL per user cannot detect a shared-key problem on a common account URL. The test must exercise the URL and identity combination the cache will actually see.
Verify invalidation and incident containment
If a rule is corrected after sensitive content may have entered cache, determine the appropriate purge scope and whether other cache layers need attention. A configuration change does not necessarily remove every previously stored representation. Preserve restricted evidence and follow the organization's incident process if cross-user exposure was demonstrated.
Keep browser cache and application caches in the investigation. Purging the edge does not erase a response already stored elsewhere. The recovery report should distinguish prevention of new caching, removal of relevant cached objects, and assessment of prior exposure rather than treating one purge action as every task completed.
Measure performance on the safe population
After isolation tests pass, measure cache hit behaviour and response time for the public routes intended to benefit. Keep authenticated traffic in a separate view so a low hit rate there is not misdiagnosed as a performance failure. Some responses should remain uncached by design.
Observe origin load, error rate, and invalidation behaviour during a normal release. A broad cache rule may make one benchmark look excellent while producing stale public content or confusing updates. Include content freshness in the acceptance criteria alongside latency.
Keep the cache contract reviewable
Document route classes, privacy headers, bypass conditions, custom-key choices if any, and the two-user test results. Version the rules through the team's normal configuration process. Add a review trigger when application authentication or personalized rendering changes.
A focused operator exercise: A same-URL identity comparison
Give two controlled accounts visibly different harmless profile markers, then request the same account URL in separate sessions after applying the candidate cache configuration. Repeat as an anonymous visitor and after logging out. Compare body content, cache evidence, and origin requests without distributing session cookies in the test report.
Also test a public page intended to remain cacheable so the team can verify the performance benefit on the safe population. The desired result combines correct private responses with useful public caching. Keep the route and authentication contract with the test, and repeat it when the application changes cookies, rendering, or account-page routing.
Quick diagnostic map
| Evidence | Review | Acceptance boundary |
|---|---|---|
| Identity boundary | Compare anonymous and signed-in responses | Detect personalized content at the same URL |
| Cache decision | Inspect bypass rules and response headers | Test cookies and authorization inputs |
| Isolation acceptance | Request the URL as two separate users | Confirm no user receives another users content |
Frequently asked questions
Does a high cache hit rate prove the rule is correct? No. Correct content and user isolation must be established first.
Clouvenix can review application response contracts and edge configuration together, helping teams improve public-page performance while keeping private content tied to the right user.
For a scoped review of this workflow, discuss the relevant Clouvenix engineering service.