News
Service Workers vs Cache-Control for Personalized Pages
October 28, 2025
Service workers vs Cache-Control for personalized pages is two caches. Cache-Control tells browsers and shared CDNs whether HTTP may store the response. A service worker sits in the page origin and can cacheRequest even when the network said no-store — that is a product choice, not a header bug. Caching /dashboard HTML or API JSON with cookies in Cache Storage is how one profile's page survives logout. Scope the worker to a prefix you understand. RoastMyOpsec does not register service workers, does not inspect Cache Storage, and does not score missing Service-Worker-Allowed. It does compare Cache-Control to Set-Cookie on the landing HTML.
The practical difference
HTTP cache is hop-by-hop policy. The worker is your JavaScript. Clearing cookies does not always clear Cache Storage. Clear-Site-Data on logout is the belt if you used a worker — see Clear-Site-Data vs cookie expiry.
A PWA for a public brochure can cache static assets. An account app should network-first for HTML and never put session bodies in Cache Storage without a threat model.
How to choose a caching plan
Static hashed assets: worker or HTTP cache, long TTL. Personalized HTML: Cache-Control private, no-store, and skip the worker cache (or cache only a logged-out shell). Logout: unregister or skipWaiting plus Clear-Site-Data caches. Do not set Service-Worker-Allowed: / unless the worker is built for the whole origin.
| Layer | Who honors it | Personalized HTML | Takeaway |
|---|---|---|---|
| Cache-Control | Browser HTTP cache, CDNs | private, no-store | See ETag vs Cache-Control |
| Service worker Cache Storage | Your script | Usually do not cache | Scope + logout hygiene |
| ETag | Revalidation | Must not be user-agnostic on a public URL | Validator, not a worker |
| Clear-Site-Data | Supporting browsers on logout | Can wipe cache | Belt with cookie expiry |
What the roast can prove
Set-Cookie plus public Cache-Control on the landing response can surface. A service-worker.js 200 is not scored. Confirm registration in your own app. Pair with the web app manifest if install is the reason you added a worker.
Common mistakes
The first mistake is cache.addAll(['/']) including the logged-in document.
The second mistake is a worker at / with scope / on a host that also serves /admin.
The third mistake is treating Cache-Control as a kill switch for Cache Storage.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Does Cache-Control no-store stop service workers?
- No. The worker can still write Cache Storage. Treat SW caching as a separate policy.
- Should brochure sites use a service worker?
- Only for static assets you are willing to cache. Missing a worker is not a roast F.
- Does RoastMyOpsec inspect service workers?
- No. It does not register workers or read Cache Storage.