Great question—this touches on a critical aspect of Chrome extension security, and it’s important to clarify both the intentional behavior here and the steps you can take to protect against misuse.

First, let’s confirm your observation:

The chrome.tabs.executeScript(tabs[0].id, {code: '...'}) method does bypass page-level Content Security Policy (CSP) headers. This is by design in Chrome: extension-injected scripts run in a separate "isolated world" context, which isn’t bound by the page’s own CSP rules. As long as the extension has been granted host permissions for the target site (either via user consent during installation or declared in its manifest), it can inject scripts regardless of what the page’s CSP says.

Now, let’s tackle your core questions:

Does CSP Protect Against This? #

Short answer: No, not directly. Page CSP is meant to restrict what resources and scripts the page itself can load and execute. It has no jurisdiction over extension-injected scripts, because those are governed by Chrome’s extension permission system, not the page’s security policies.

That said, CSP isn’t completely irrelevant here: if your page uses a strict CSP that blocks inline scripts, it won’t stop the extension’s injected code, but it will prevent the extension from using inline script execution within the page’s context (a minor edge case, but worth noting).

How to Protect Against Unauthorized Extension Access #

To safeguard sensitive data like cookies and localStorage from malicious or overreaching extensions, use a layered approach of browser, server, and page-level measures:

• Mark Sensitive Cookies as HttpOnly: Any cookie with the HttpOnly flag can’t be accessed by JavaScript—including scripts injected by extensions into the page context. Note that extensions can still access HttpOnly cookies via the chrome.cookies API if they have the explicit cookies permission, but this requires a separate permission grant that users are more likely to question.

• Use SameSite Cookie Attributes: Setting SameSite=Strict or SameSite=Lax limits when cookies are sent in cross-site requests. While this doesn’t stop extensions from reading the cookies, it reduces the risk of the extension using those cookies to perform unauthorized cross-site actions on the user’s behalf.

• Be Wary of Extension Permissions: As a user, always review the permissions an extension requests before installing it. Avoid granting <all_urls> access unless the extension has a clear, legitimate need (like a password manager that works across all sites). As a developer, follow the principle of least privilege—only request host permissions for the specific sites your extension actually needs to interact with.

• Enable Chrome Site Isolation: This built-in Chrome security feature isolates each site in its own process, making it harder for malicious extensions to exfiltrate data across different sites. It doesn’t block script injection entirely, but it adds an extra layer of isolation that limits cross-site data leakage.

• Detect Injection in Your Page: You can add heuristic checks to your page to spot unexpected script injection, such as:

  • Monitoring for dynamically added script tags that don’t match your expected resources
  • Checking for unusual changes to the window object or global scope
  • Using MutationObserver to track DOM modifications that could indicate injection
    Keep in mind that determined extensions can bypass these checks, but they can deter casual misuse.

• Enterprise Controls: For organizations, use Chrome Enterprise Policies to manage extension installation. You can block untrusted extensions, create an allowlist of approved tools, or restrict high-risk permissions like tabs or cookies for unvetted extensions.

A Quick Note on Chrome Web Store Review #

You mentioned assuming your extension would pass review if submitted—don’t count on it. The Chrome Web Store has strict policies against extensions that misuse permissions, including accessing user data without a clear, legitimate purpose. If your extension reads cookies/localStorage across sites without a valid use case (like a clearly labeled security testing tool), it will almost certainly be rejected during the review process.

内容的提问来源于stack exchange，提问作者Mike Smedley