> While Manifest V3 extensions can't use code that isn't bundled with the extension
Does this mean they're not allowed to write to the DOM? Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
Also, the example shows a use of fetch. What keeps the script from eval-ing a string from the result of that fetch?
> Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
By my understanding, this is still possible. If you dynamically inject a script tag, your code runs in the JS context of the page itself.
On the other hand, the chrome.tabs.executeScript API referred to in this article injects a "content script", which runs in an isolated world and has access to all of the same extension APIs that statically-deployed code does. As I understand it, this is what they're really aiming to prevent: dynamically-loaded code that runs in the extension's privileged context.
> Also, the example shows a use of fetch. What keeps the script from eval-ing a string from the result of that fetch?
As I mentioned in another comment, Manifest V3 bans the use of eval() in extension code. If you inject a script tag into a page, that script may or may not be allowed to call eval(), depending on the page's content security policy.
> Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
No they couldn't, because CSP still applies. Even if the extension itself can inject a script element as DOM node, the actual loading of the script's source would still get blocked because it's not being loaded from a trusted source.
The company I am working at develops a kind of overlay with helps that can be displayed on a given website.
When we are lucky, our clients can add a script tag to their applications (and tweak their CSPs if they have), when we are not we have to rely on a web extension (think a kind of Tampermonkey but more specialized and with our branding and without a new tab every other day to tell it has been updated).
What do we use ?
- Blocking webRequest to change CSP to authorize our overlay script to execute
- executeScript: in most case, the script we execute is just inserting a script tag so it would still work in Manifest v3, but with webapps using Service Worker we have to resolve to download the scripts and execute then directly via executeScript, which will not be possible in v3.
Guess we'll have to bundle the overlay engine in the extension, which is much less flexible than what we had until now, but at least it's a possibility.
Original blog post author here. Some quick personal thoughts (i.e. I'm not speaking on behalf of Chrome here).
> - Blocking webRequest to change CSP to authorize our overlay script to execute
I can't exactly say I'm keen on extensions relaxing CSP rules for a site. The approach I'm interested in exploring here is allowing extension resources to bypass CSP restrictions on a given site. IMO a typical extension shouldn't be able to weaken a site's security, but it should be able to load its own images and scripts on the site.
> - executeScript: in most case, the script we execute is just inserting a script tag so it would still work in Manifest v3, but with webapps using Service Worker we have to resolve to download the scripts and execute then directly via executeScript, which will not be possible in v3.
This is not a viable approach in Manifest V3 as reviewers would consider this remote code injection and therefore a violation of the "Additional Requirements for Manifest V3" section of the policy.
Bundling the overlay engine with the extension sounds like it may do the trick. Just make sure that the engine cannot be used for malicious purposes (e.g. harvesting user data, arbitrary script injection, etc.).
Does the script element injected as a DOM node from an extension or a content script end up having a different CSP than a script element that loaded with the page or was injected by a script on the page?
Does this mean they're not allowed to write to the DOM? Because if they are allowed to write to the DOM, they can just add a script tag that loads a script from an arbitrary URL.
Also, the example shows a use of fetch. What keeps the script from eval-ing a string from the result of that fetch?
Am I misunderstanding the security model here?