07 · Configure Cache Rules with an allowlist mindset
Identify identity and write paths first, then admit only known public resources to cache and verify correctness with rule order, Trace, and two clients.
Edited and verified by Orange Book Editorial Team ·
Outcome
You will have a small, explainable rule set: fingerprinted assets can use a long cache lifetime, selected public content can start with a short lifetime, and sign-in, account, administration, preview, payment, webhook, and write requests cannot enter shared cache.
Start with a content matrix, not Cache Everything
| Content class | Typical path | Initial policy | Release evidence |
|---|---|---|---|
| Fingerprinted assets | /assets/app.abc123.js | Eligible; respect origin or use a long TTL | MISS → HIT; a new version URL works |
| Public content | /blog/*, /docs/* | Eligible only on named paths; short TTL first | Anonymous clients agree; targeted purge is possible |
| Identity pages | /login, /account/* | Bypass | Cookies, CSRF, sign-in, and sign-out work |
| Write APIs | Non-GET/HEAD, /api/private/* | Bypass | Requests reach the app and responses never cross users |
| Admin and preview | /admin/*, /preview/* | Bypass | Draft and admin data never hit anonymously |
| Payment and callback | /checkout/*, /webhooks/* | Bypass | Signatures, idempotency, and updates are unaffected |
Cache Rules apply only to Proxied hostnames. Eligible for cache allows Cloudflare to attempt caching; it does not guarantee storage. Origin Cache-Control, Set-Cookie, status codes, and other settings still participate.
Rules stack; the last matching value wins a conflict
flowchart TD
A[Request enters Cache Rules phase] --> B[Evaluate matching rules in order]
B --> C{More than one match?}
C -- No --> D[Apply the single result]
C -- Yes --> E[Different settings can combine]
E --> F[For one conflicting setting, last match wins]
F --> G[Use Cloudflare Trace to prove the result]Make public and sensitive expressions mutually exclusive where possible. If they must overlap, place a broad public Eligible rule first and the specific sensitive Bypass later so the last result remains bypass. Re-run Trace after reordering because Cache Rules also take precedence over legacy Page Rules on the same path.
Build the minimum policy in the dashboard
Capture paths and response headers
Use the route table, frontend Network panel, server logs, and sitemap to list public, identity, write, preview, and asset routes. Do not ask AI to infer data sensitivity from filenames alone.
Create the public-asset rule
Open Caching → Cache Rules for the zone and choose Create rule. Use Hostname plus URI Path or File extension to constrain the rule to a verified static directory, then select Eligible for cache. Respect origin headers in the first version; do not simultaneously alter the key, query handling, and every status-code TTL.
Create sensitive bypasses
Choose Bypass cache for identity, account, payment, administration, preview, private API, and write traffic. If a bypass can match the public rule, place it later. Better still, exclude sensitive paths from the public expression so intent does not depend on hidden order.
Save a draft and inspect with Trace
The dashboard can save a Draft. Use Cloudflare Trace on the homepage, a static asset, sign-in, account page, public API, and one write endpoint. Record matched rules, final Cache eligibility, and ordering before deploying to a test hostname.
Verify anonymously and with two accounts
curl -sS -D - -o /dev/null https://www.example.com/assets/app.abc123.js
curl -sS -D - -o /dev/null https://www.example.com/loginThese commands establish only the cookie-free baseline. Also use an anonymous browser and two independent test accounts for sign-in, sign-out, account pages, form submission, and CSRF. Account A must never receive content from account B.
Bypass can appear as DYNAMIC
A custom Bypass rule can make the request ineligible at request time, so the response may say CF-Cache-Status: DYNAMIC rather than literally BYPASS. Combine Trace, rule matches, and complete headers when interpreting it.
Release gates
- Every rule is constrained to a listed Hostname and URI range.
- When rules overlap, the final matching rule cannot make a sensitive path Eligible again.
- Static objects show an explainable
MISS → HIT; identity and write routes stayDYNAMICorBYPASS. - Two accounts complete sign-in, sign-out, reads, and writes without cookie, CSRF, or cross-user data errors.
- Rollback disables the new rules; it does not delete origin security headers or purge the entire zone.
For a shorter implementation checklist, see the safe login and API recipe. Next, separate Edge TTL, Browser TTL, and response headers.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.
06 · Understand Cloudflare's default cache behavior
Use request eligibility, file extensions, response headers, default TTLs, and CF-Cache-Status to explain why an object hits or bypasses cache.
08 · Edge TTL, Browser TTL, and cache response headers
Separate browser, Cloudflare edge, and origin cache lifetimes, then use Cache-Control and CDN-Cache-Control to build an updateable release policy.