Service Workers are scripts that run in the background, separate from web pages, enabling features like offline functionality and push notifications. While powerful, they require careful security consideration as they can intercept and modify network requests. They must be served over HTTPS and follow same-origin restrictions.
A service worker is a JavaScript file the browser registers to run in the background, decoupled from any single page and even when no tab is open. It sits as a programmable network proxy between the site and the network: through the fetch event it can intercept outgoing requests, answer them from a cache, rewrite them, or pass them on. That is what powers offline experiences, background sync, and push notifications in progressive web apps. Service workers are event-driven and have no DOM access; they communicate with pages via messaging. Registration is tightly constrained, they must be served over HTTPS, obey the same-origin policy, and their scope is limited to the path from which they are served.
Because a service worker can intercept and rewrite every request within its scope and persists across sessions, it is an unusually powerful and durable position on the client. If an attacker manages to register a malicious worker, for example through an upload endpoint that serves attacker-controlled JavaScript at a broad scope, or by exploiting an existing script-injection flaw, they gain a persistent man-in-the-browser foothold that survives page reloads and can silently manipulate traffic, serve fake content, or harvest data long after the original entry point is closed. The HTTPS and same-origin requirements exist precisely because this capability would be catastrophic if a network attacker or a foreign origin could plant one.
Lock down where scripts can be served from so an attacker cannot host a worker at a useful scope: sanitize and content-type user uploads, avoid serving user-controlled JavaScript from your origin, and constrain registration scope with the Service-Worker-Allowed header. A Content Security Policy with worker-src restricts which scripts may become workers, and Subresource Integrity plus review of build pipelines guards the legitimate worker file itself. cside complements this by proxying and analysing the third-party scripts a page loads and blocking malicious behavior in real time; the resulting forensic record of executed code helps investigators reconstruct how a rogue worker or injected script reached the browser.
A service worker has no direct DOM access and cannot touch document.cookie, since it runs off the main thread. However, it can intercept network requests within its scope and inspect or modify their headers and bodies, which gives it substantial influence over the data flowing to and from the page.
A service worker can intercept and rewrite all network traffic in its scope, so allowing one to be installed over plaintext HTTP would let a network man-in-the-middle plant a persistent proxy in the victim's browser. Requiring HTTPS ensures the worker script is authenticated and untampered before the browser grants it that power.
We answer client-side security questions every day. Bring yours.