Pwa

Service Workers and CSP have an awkward relationship. A lot of developers assume CSP either fully controls what a Service Worker can do, or barely touches it at all. Neither is true. The browser applies CSP in a few very specific places, and if you get those wrong, your worker won’t register, won’t update, or will quietly fail in ways that are annoying to debug. I’ve seen teams lock down page CSP nicely, then wonder why their offline cache logic broke after moving sw.js behind a CDN path, or why a worker-installed fetch started behaving differently than page fetches. The root problem is usually the same: they’re treating the page, the worker script, and worker-initiated requests as one security context. They aren’t. ...

Progressive web apps make CSP slightly weirder than normal websites. A regular site mostly loads fresh resources over the network. A PWA keeps working when the network is gone, which means scripts, HTML, and API responses may come from the service worker cache instead of the server. That changes how people debug CSP failures, and it changes how you should think about policy rollouts. The short version: cached resources still need to obey CSP. Offline support does not bypass browser enforcement. But service workers can absolutely make CSP behavior confusing if you cache old HTML, stale JS, or third-party responses that no longer match your current policy. ...