A service worker can sit between a page and the network, modify responses, and keep assets in persistent caches. That makes it useful for offline experiences and performance. It also gives JavaScript a durable position in the browser's request path. The registration scope determines how much of the origin that position can influence, and the update and cache behavior determines how long a bad or compromised worker can remain active.
Service workers require a secure context in normal browsers. They run in a worker context without DOM access, but they can intercept navigation and resource requests within their scope. The script's location constrains the default scope. A broader scope needs deliberate registration and server support, such as the appropriate Service-Worker-Allowed response header.
Keep the scope narrow
Register the worker from the narrowest path that needs offline behavior. A worker at /product/sw.js naturally controls the product subtree rather than the whole site. If a root scope is required, document why and test how the worker handles unrelated applications, authentication callbacks, and administrative paths. A broad scope increases the number of requests whose behavior depends on one script and its cache policy.
Review the response headers and content type of the worker script. Serve it with a valid JavaScript media type and a cache policy that allows updates. Use a Content Security Policy worker-src directive or its documented fallback to control which scripts may create workers. The server should not allow an uploaded file or a user-controlled template to become the worker source.
Treat caches as stored data
The Cache API stores request and response pairs, including static assets and API responses. An application can accidentally place authenticated JSON, personalized HTML, or API responses into a cache that another page context later reads. Use cache keys that include the relevant user or session boundary, and avoid caching responses that carry credentials or private data. Clear obsolete caches during activation and on logout where the application's data model requires it.
An XSS flaw in a controlled page is already serious. If it can register or modify a service worker, the effect may outlive the page view and affect subsequent requests. Content sanitization, CSP, dependency review, and worker origin controls therefore reinforce one another. The service worker does not create the injection flaw, but it can make recovery harder.
Design updates and rollback
The browser controls when a new worker takes control. A worker may remain active while old pages are open, and a cache may contain both old and new assets. Define a versioned build identity, a clear activation policy, and a safe fallback for incompatible API changes. Do not assume that deleting a cache name in source code immediately removes the old worker or every cached response.
Test these cases:
first installation on a clean profile
update while an old tab remains open
rollback to a previous worker version
offline startup with the current cache
logout and account switching
a request outside the intended scope
a worker script with the wrong content type
Inspect the browser's application panel or DevTools and confirm the active worker, scope, cache names, and response headers. A server-side deployment report is not proof that the user's browser has adopted the new version.
Monitor for control changes
Track worker script changes, scope changes, and cache version changes as release events. Alert on unexpected root-scope registration from a product path. Keep a tested emergency process that can disable registration, invalidate caches, and restore a known-good worker without requiring an unsafe permanent bypass of HTTPS.
Service workers are a powerful browser feature with a finite but important trust boundary. Start with the requests the script can alter, the data it stores, who can update it, and how the application recovers when the script or its cache is wrong.