Extension service workers explained for security reviewers

In Manifest V3, an extension's service worker is its central event handler. It loads when needed, shuts down when idle, and has no DOM access. It is where powerful extension APIs and cross origin network requests usually live, so it is the first place a security reviewer should read.

What it is

Chrome's documentation calls the extension service worker the extension's central event handler. Unlike a web service worker, which is mostly described as a network proxy, it also responds to extension events such as a tab closing or a notification click.

Lifecycle

The worker is loaded when it is needed and unloaded when it goes dormant. While it receives events, it generally keeps running, but even then it can shut down. For developers that means no assumptions about long lived in memory state.

For reviewers, this has a security angle. Because state cannot live in memory, extensions persist it in storage. Chrome notes that extension storage is not cleared when a user clears browsing data, so anything an extension saves may remain after you wipe your history.

No DOM, so who touches pages?

A service worker cannot work with the DOM directly. If an extension needs DOM access, it can use offscreen documents. To affect a page, the worker usually injects or messages a content script. See content scripts and isolated worlds.

Network access

Chrome states that service workers and foreground tabs can reach remote servers outside their origin if the extension declares host permissions. Cross origin requests from extension contexts are not limited by CORS the way ordinary web pages are, once host permissions are granted. This is why the worker is the likely exit point for any collected data.

A reviewer's checklist

1. Which hosts does the extension declare? That bounds where the worker can send requests.
2. What does it fetch, and is any of it treated as code? Remote logic is not allowed under store policy, but misuse of data as logic is worth checking in source.
3. What does it store, and for how long? Look for tokens, URLs and page content in storage.
4. Which messages does it accept from content scripts, and are they validated?
5. Does it build request URLs from message content? Chrome advises sending only parameters like an item ID and building the URL inside the extension.

Why this is useful even if you are not a developer

You can unzip an extension package or find its folder on disk and open its service worker file. Even skimming for fetch calls and storage writes tells you more than a store description will.

Quick check

Sources

• Extension service workers (Chrome for Developers)
• Cross origin network requests (Chrome for Developers)
• Storage and cookies (Chrome for Developers)

Last reviewed: 19 October 2026.