Cloudflare Cache Privacy: Test Public and Personal Responses Separately

A cache policy is correct only when it preserves who may see the response. Faster delivery does not compensate for serving account-specific data to another visitor. Review public content and personalized responses as different classes, even when they share a hostname.

Cloudflare's cache-control documentation explains the distinction between directives such as private and no-store. The effective result also depends on configuration. Inspect both the origin response and the rules applied along its delivery path.

Classify responses before setting lifetimes

List a few representative routes: a public help page, a signed-in account page, an export and a login response. For each, identify whether the body or headers contain information specific to a user.

Include variation that is easy to miss. A public article might contain a personalized saved-state widget, while a separate API call supplies private information. The cache boundary follows the actual response, not the page's marketing label.

Document which responses may be shared and which must remain private. Keep that decision close to the implementation so a later “cache everything” optimization can be reviewed against it.

Distinguish processing location from delivery

ComprimirPDF describes browser-local PDF compression and is declared in the Cloudflare catalogue. A locally processed document and a cached public application shell are different data flows. The listing's privacy description should not be extended into assumptions about every network request.

For your own file-oriented application, draw the path of the file bytes separately from the delivery of HTML, scripts and images. That makes it possible to improve static delivery without accidentally treating user documents as reusable assets.

Do not upload confidential material merely to investigate the architecture. Synthetic files can establish the intended flow in an authorized test.

Use two isolated identities

Create distinct test accounts in an environment you control. Give each recognizable synthetic data. Request the relevant response as account A, then account B, then an anonymous visitor.

Inspect both the body and the relevant cache headers. Confirm that private values never appear in the wrong context. Repeat with a warm cache and after a normal content update.

This test should complement configuration review. A small passing sample is evidence about those cases, not a proof that every route is safe.

Check the complete delivery chain

A browser cache, application cache and shared CDN cache can behave differently. An origin directive that looks correct is not enough if another layer rewrites it or stores a broader response.

Keep an inventory of rules that change caching based on cookies, paths or headers. Review overlaps and exceptions. For sensitive routes, prefer an understandable explicit policy over a collection of compensating assumptions.

When a response changes from public to private, test that transition as a separate release concern.

Treat failures as boundary defects

If a fixture crosses identities, stop the affected test and fix the policy before tuning performance. Record the route, identity state, cache state and rule responsible. Avoid logging actual secrets while investigating.

The companion Cloudflare content-update verification guide checks freshness after a safe cache boundary exists. For the broader distinction between CDN delivery, hosting and compute, use the Cloudflare architecture guide.