Orange Book
Recipes

Recipe: Cache Rules that do not break sign-in or APIs

Bypass identity, account, and write paths first, cache only public content, and verify the policy with headers and separate clients.

Edited and verified by Orange Book Editorial Team ·

RECIPE · SAFE CACHINGAbout 24 minutesCache Rules · sign-in · APIs

Safe order of operations

Define paths and responses that must never be cached before enabling caching for a narrow public surface. Sign-in, accounts, carts, checkout, administration, authenticated APIs, and write requests bypass by default. Do not begin by enabling Cache Everything across the site.

Fill in this matrix first

Route classExamplesDefault actionWhat to verify
Fingerprinted static asset/assets/app.abc123.jsCache; a long TTL can be appropriateRepeats become HIT and a versioned URL updates
Public content/blog/*, public product pagesHonor origin headers or use an explicit cache ruleSigned-out and separate clients see the same public response
Identity and transaction/login, /account/*, /cart/*, /checkout/*BypassSet-Cookie, CSRF, and user data never enter shared cache
API/api/*Bypass by default; create a separate rule for a proven public GETMethod, Authorization, Cookie, and response privacy
Admin and preview/admin/*, /preview/*BypassDraft and management responses are not readable anonymously

Release from low risk to high risk

Capture response headers before the change

curl -sS -D before.txt -o /dev/null https://example.com/assets/app.css
curl -sS -D - -o /dev/null https://example.com/account

Record URL, status, CF-Cache-Status, Cache-Control, Set-Cookie, Vary, and time. Do not purge the entire zone first.

Add high-priority bypass rules

Match sign-in, account, cart, checkout, administration, preview, and authenticated API paths first. A write method must not enter shared cache merely because its URL looks public. Use the current Cache Rules expression editor and record a business owner for each rule.

Cache one public resource set

Start with fingerprinted static assets or one path proven to contain no personal data. Do not change cache key, origin headers, TTL, and every route in one release; test one hypothesis at a time.

Verify anonymous and signed-in clients separately

Request the public asset twice in a clean cookie-free session, then use two separate test accounts for protected pages. Success means more than a public HIT: account A must never see account B's content, and sign-in and CSRF flows must still work.

Add expiry and revalidation intentionally

Before using stale-while-revalidate, understand asynchronous revalidation: the first expired request can see UPDATING. must-revalidate, proxy-revalidate, s-maxage, and no-cache affect whether stale responses may be served. Decide from freshness and privacy requirements, not hit rate alone.

Cache Everything can break sessions

Aggressive full-page caching can interfere with Set-Cookie, sessions, and CSRF. If failures begin after a cache-everything policy, narrow or disable that rule and restore identity routes first. Do not remove security cookies merely to increase cache hits.

Release and rollback gate

  • The rule covers only listed public paths, with higher-priority bypasses for identity routes.
  • Two test accounts complete sign-in, sign-out, account reads, and writes.
  • A public object produces an explainable MISS → HIT or revalidation state under identical conditions.
  • Disable the new rule immediately after cross-user data, sign-in loops, CSRF failures, or unexpected Set-Cookie behavior.
  • Repeat the original read-only requests after rollback and confirm headers and behavior recover.

If a response still does not hit as expected, preserve evidence with the CF-Cache-Status troubleshooting guide.

Primary sources

Did this page help you complete your goal?

Beta feedback is generated in this browser and is never uploaded automatically.

On this page