Clarification: Is it expected that a MV3 content script (no permissions) can read authenticated responses on the same matched Google-owned origin?

[Eliate Elderson]

Dear Team,

I am writing to seek clarification on a potential security boundary violation I have observed while auditing extension behavior on Tier 0 Google origins, specifically docs.google.com.

According to the developer documentation for Content Scripts, content scripts live in an Isolated World to prevent interference with the host page. However, my testing reveals a configuration on Google Sheets that appears to allow a "Limited Permission" extension (restricted to docs.google.com) to escalate its impact far beyond simple DOM interaction.

The Observation: When an extension is active on a Google Sheet, the Chrome DevTools console explicitly triggers the following warning:

"An iframe which has both allow-scripts and allow-same-origin for its sandbox attribute can escape its sandboxing."

The Counter-Questions for Clarification:

Sandbox Escape as a Feature: 

Does the Chromium team consider the presence of the allow-scripts and allow-same-origin flags on the primary Google Sheets editor iframe to be a "known and accepted risk"? My testing shows this configuration allows a content script to bridge the gap between the sandboxed editor and the top-level authenticated session, facilitating the silent exfiltration of raw spreadsheet data to an external origin via fetch().

Bypass of HttpOnly Protections: In this specific "Escape" context, I have observed that sensitive session identifiers (which I understood to be protected from JavaScript via the HttpOnly flag) become accessible for exfiltration. Does the "Isolated World" model officially support reading HttpOnly cookies when the site's own sandbox configuration is weakened?

Data Exfiltration vs. Intended Access: While content scripts are designed to "read and change data," does the VRP consider it intended behavior for a restricted extension to programmatically scrape and transmit an entire private document's contents to a non-Google origin without any specific "Data Export" permission or user gesture?

If an extension can leverage a site-specific sandbox misconfiguration to exfiltrate full-document state and identity tokens, does this not qualify as "access to site data without an API or permission that allows this access," as defined in the Extensions Security FAQ?

I have not filed a formal bug report yet as I am first seeking to understand if this "Sandbox Escape" is a documented exception to the Chrome Extension Security Model.

Regards,
Eliate

[Oliver Dunk]

Hi Eliate,

This mailing list is not monitored by anyone responsible for reviewing VRP reports, but I can provide some high-level thoughts from an extensions perspective.

The ability to scrape data from a page you are running a content script on sounds like intended behavior as described under the "I've found / written an extension that can access sensitive user data, like passwords and emails. Is this a security bug in Chromium?" heading of the Extensions Security FAQ. There is no specific data export permission or user gesture requirement. Declaring a content script in your extension manifest triggers the same install-time warning as requesting host permissions, and as such the user is allowing the extension full access to the data on the origin. Being able to transmit the data does not change anything here.

I wasn't able to find the sandboxed iframe you mentioned in Google Sheets. However, the "misconfiguration" there would not be a Chromium bug, as Chromium is not responsible for individual web pages. It could be a Google Sheets issue (which I'm sure is also covered by the VRP) but it is also very possible this usage is intentional.

Accessing HttpOnly cookies should not be possible from any in page JavaScript context. If you can do this, that would definitely be a security bug.

According to the developer documentation for Content Scripts, content scripts live in an Isolated World to prevent interference with the host page.

Could you share the specific documentation you are referring to? This does not sound like an accurate summary of the goals or boundaries provided by a content script. Content scripts run in a separate JavaScript world which provides some isolation of global context. For example, running `window.foo = "bar"` in one world will not affect `window.foo` in another. However, in most other ways they have an equal level of access to the document. Isolated worlds are definitely not intended to make it safer to run an untrusted extension on a page.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/5e0846ea-87bb-4ef3-a049-8617df2ecd7cn%40chromium.org.

[Eliate Elderson]

Hi Oliver,

Thank you for the detailed response. I really appreciate the clarification!

I had one follow-up question related to extension behavior that I wanted to confirm, to ensure I’m understanding the intended security boundaries correctly.

what I used:
content_script running on https://docs.google.com/*
host_permissions include https://mail.google.com/*

Observation:
From the Docs page, the extension is able to fetch authenticated resources from mail.google.com (for example, the Gmail Atom feed), even when mail.google.com is not opened in any tab.

In DevTools, I sometimes see CORS-related console errors such as:
“Access to fetch at 'https://mail.google.com/…
' from origin
'https://docs.google.com
' has been blocked by CORS policy”

However, despite the console message, the response data is still accessible to the extension.

Question is:
Is this behavior expected for extensions with explicit host_permissions, even across different Google properties (e.g., Docs → Gmail), or is there any intended isolation between these services that extensions should not be able to cross?

This is purely a clarification question to better understand the extension security model, not a vulnerability report.

Thanks again for your earlier guidance and for helping clarify the intended behavior.

Regards,
Eliate

[woxxom]

If the extension has the background script (declared in manifest.json) it can fetch from any origin in its host_permissions and then provide the result to its content scripts running in the web page.

[Oliver Dunk]

You should not be able to read response data for requests to mail.google.com from docs.google.com, unless the relevant CORS headers are present. If you are sure you can do that, it would be a security issue.

As woxxom mentioned, host permissions allow privileged contexts like an extension background page to bypass CORS. However, they should have no impact on the behavior of requests made in a content script.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Eliate Elderson]

Hi Oliver,

Thanks for the clarification, this helped me a lot in understanding how Chrome enforces these boundaries.

To confirm my understanding:

I agree that host permissions allow privileged extension contexts (background/service worker/devtools) to bypass CORS, and that this behavior is expected.

I also agree that content scripts must remain subject to normal SOP/CORS, and host permissions or DNR rules should not affect their ability to read cross-origin response bodies.

My remaining question is to validate the boundary:

If a content script (running on docs.google.com), without relaying requests through a background/service worker and without message passing, is able to read response data from mail.google.com due to extension configuration (e.g., DNR header modification or other extension APIs), would that be considered a Chrome security issue?

I want to ensure I am testing within the correct threat model and not misclassifying expected extension behavior as a vulnerability.

Regards,
Eliate