Where can a browser extension send your data? Network rules explained

An extension can send data to any server its host permissions cover. Chrome's documentation says service workers and extension pages can reach remote servers outside their origin once host permissions are declared, while content scripts follow the page's origin rules. So host permissions bound where data can go.

Three places code runs

The extension's own origin. Each extension has its own security origin. Without extra privileges, it can fetch its own bundled files.

Service workers and extension pages. With host permissions declared, they can talk to remote servers outside their origin. Chrome notes that cross origin requests from extension contexts are not limited by CORS the way ordinary web pages are, once the permissions are granted.

Content scripts. They run in the page's origin. The documentation states that cross origin requests are always treated as such in content scripts, even if the extension has host permissions. The recommended design is to ask the service worker to make the request.

What this means for data flow

Here is the typical path for a tool that reads text on a page:

1. A content script reads the text from the page.
2. It sends a message to the service worker.
3. The service worker calls a server using host permissions.

Step 3 is where data leaves. The host permission list therefore shows you the possible destinations. If a tool claims to work offline but declares access to many remote hosts, ask why.

Host permission format

Hosts can be written as a fully qualified host or a match pattern. Path information is ignored. Schemes are separate, so http and https access must be declared individually. See match patterns explained for reading them.

Practices from Chrome's guidance

Developers are advised to avoid certain mistakes, and users can ask whether a vendor follows them:

• Do not let content scripts pass arbitrary URLs to fetch logic. Send parameters such as an item ID and build the URL inside the extension.
• Avoid innerHTML with fetched content. Use textContent or safe parsing.
• Prefer HTTPS over HTTP.
• Treat custom content security policy changes carefully.

A quick review recipe

1. List the host permissions.
2. For each host, ask whether the feature needs it.
3. Check that requests use HTTPS.
4. Look for a privacy statement that names what is sent and where.
5. Narrow site access in the browser to limit what content scripts can read in the first place. See Chrome site access settings.

Quick check

Sources

• Cross origin network requests (Chrome for Developers)
• Content scripts (Chrome for Developers)
• Match patterns (Chrome for Developers)

Last reviewed: 19 October 2026.