1267027 - [meta] Page CSP should not apply to content inserted by content scripts (V2 issue)

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Kris Maglione [:kmag]]

+++ This bug was initially created as a clone of Bug #1207394 +++

This is a follow-up to bug 1254194 comment 29.

In Chrome, web page CSP is not supposed to apply to content inserted by a content script. So, the following should all work, in theory:

* Injecting an inline <script> node should execute the script in a page with "script-src 'none'"
* Injecting an image from "http://example.com" into a page with "default-src 'self'" should load the image.

The following do not work in Chrome, but they seem to prefer that they would:

* Injecting a node with an "onclicked" listener into a page with "script-src 'none'" does not execute the listener, because the script is not executed during the call from the content script that created it.

Comment 2

[Kris Maglione [:kmag]]

Dan, do you have any thoughts on how much of this behavior we want to copy? I'm actually not inclined to implement it at all, except to the extent that add-ons should be allowed to inject resources packaged with the extension.

Comment 3

[Daniel Veditz [:dveditz]]

We favor the desires of the user above the page author. We usually assume that the add-on is acting on the user's behalf (the user chose to install it) so it'd be nice if add-ons could bypass CSP. Although sometimes they do slimy stuff for themselves so it's also nice when what they're doing is explicit so reviewers can check it out.

We also are fighting an architecture that is hard to change. If something sticks in an <img> tag, that results in an image load generated by that page. At the networking/nsIContentPolicy level where CSP is enforced we can't tell the difference between script in the page creating that <img> tag and an add-on or chrome creating it.

This is not special to web extensions, and we have essentially this feature request for regular add-ons on file somewhere; I'd call this a dupe of that one. But you're here and seem to have the energy to fight this battle so here are two possible ways to "fix" it.

a) What I've suggested before is to add a method to the internal CSP that lets us expand the policy, rather than the current mechanism that only lets additional content policies tighten the policy. So a Flickr mashup could call this API and add "img-src *.flickr.com" or maybe "all-src *.flickr.com" (I just made up all-src -- we'd need something to override all policies, not a default to be used if other policies weren't set). For WebExtension and Add-on SDK addons this override could be in the add-on metadata (e.g. manifest.json) and easy to review for sanity.

b) I don't think we know in all the places, but it's possible that for DOM-based insertion (as opposed to parser-based like setting innerHTML) we still know the script principal by time we're calling AsyncOpen2 and can use that rather than the page principal. I get 167 non-test hits for AsyncOpen2 so this would be a painful and error-prone approach.

Comment 4

[Kris Maglione [:kmag]]

OK, I'll try to figure out how doable this is, then.

I think we should still respect some restrictions, though, and at least forbid loading non-secure resources into secure pages with policies that forbid it.

Comment 5

[github]

I'm facing the same problem right now with my extension. I would opt for bypass CSP. As Daniel Veditz mention, the user chose to install the add-on with all pros (new features...) on cons (permissions request...). So CSP is just another entry on that list, depending on your point of view part of pro or con ;)

What would be a good workaround around this to bypass the CSP? I was thinking about using a background script, but that sounds like a lot of overhead just to make my extension working in Firefox.

Comment 6

[jshackles]

Any word on when this might get fixed?  Several of my addon's beta testers are running into this bug, and a lot more of the regular users will probably be experiencing it next month when Firefox 48 releases.

Comment 7

[Kris Maglione [:kmag]]

This won't be fixed any time in the next few months.

Comment 8

[The 8472]

A possible solution: Provide an API to convert blobs to moz-extension: URIs. AIUI those URIs bypass CSP, unlike blob: URIs. So images could be downloaded as blob via XHR, converted to an extension URI and then injected as <img src="moz-extension:...">

It requires extra work by addon authors, but that way the browser won't have to track which parts of the DOM would have to be treated as privileged somehow. The concept of DOM ownership is murky anyway. It's a shared resource between addons and the page.


An alternative would be an API that allows addons to whitelist patterns of content they intend to load into a page. The downside is that it is more coarse-grained than the blob approach and thus increases the potential exploit surface - but only by the whitelist - for malicious scripts that makes it into the site.

Comment 9

[Kris Maglione [:kmag]]

(In reply to The 8472 from comment #8)
> A possible solution: Provide an API to convert blobs to moz-extension: URIs.
> AIUI those URIs bypass CSP, unlike blob: URIs. So images could be downloaded
> as blob via XHR, converted to an extension URI and then injected as <img
> src="moz-extension:...">

It would be much easier to just treat blobs with moz-extension: origins as CSP-exempt, like we do for moz-extension: URLs themselves. Feel free to file a separate bug for that, and I'll look into implementing it.

> It requires extra work by addon authors, but that way the browser won't have
> to track which parts of the DOM would have to be treated as privileged
> somehow. The concept of DOM ownership is murky anyway. It's a shared
> resource between addons and the page.

This is something that we're going to have to do regardless.

Comment 10

[Andy McKay]

Possible dupe mentioned in comment 3 is bug 615708.

Comment 13

[The 8472]

On the GM issue tracker[0] the idea was brought up to inject per-userscript nonces into each -src rule of CSPs for each page load which could then be exposed to content scripts via an API. I think this is cleaner than "DOM ownership" because ownership could easily lead to transitive privilege leaks if that also applies to <script> or <iframe> elements.


[0] https://github.com/greasemonkey/greasemonkey/issues/2046#issuecomment-304908132

Comment 14

[Bryan Clark (DevTools PM) [:clarkbw]]

It looks like the Augury team has run into this issue where they can't inject their own scripts via a content script.

https://github.com/rangle/augury/blob/dev/src/content-script.ts#L32

Comment 15

[Kris Maglione [:kmag]]

(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #14)
> It looks like the Augury team has run into this issue where they can't
> inject their own scripts via a content script.
> 
> https://github.com/rangle/augury/blob/dev/src/content-script.ts#L32

Content from extensions should be immune to CSP. They just can't inject web content which would violate a page's CSP.

Comment 16

[Rory O’Kane]

Bug 866522 is related; it’s about JavaScript in bookmarklets instead of in WebExtensions. The fixes for both bugs probably share a lot of the same work.

Comment 17

[Kuba Niewiarowski]

Duplicate of bug 615708?

Also related to bug 1389874.

Comment 18

[:Harald Kirschner :digitarald]

This is breaking crucial devtools extensions on CSP secured pages.

Redux:
  Filed in https://github.com/gaearon/redux-devtools/issues/380#issuecomment-329085853
  Script is injected here: https://github.com/zalmoxisus/redux-devtools-extension/blob/ec3c33d7e2db17df13d3dfe06d02e12da3feee6c/src/browser/extension/inject/pageScriptWrap.js#L10

Augury
  :clarkbw mentioned in Comment 14 with code linked similar to the inject pattern from Redux.

More addons that are not converted to extensions yet will run into this.

ni? :mconca for input on prioritizing this from a web extension product perspective.

Comment 20

[Rob Wu [:robwu]]

The CSP spec is explicit about whether CSP should affect extensions:
https://www.w3.org/TR/CSP/#extensions

> Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
> 
> Moreover, applying CSP to these kinds of features produces a substantial amount of noise in violation reports, significantly reducing their value to developers.
> 
> Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.

Comment 21

[Mike Conca [:mconca]]

Thanks to everyone for the constructive comments. We are currently targeting to have this feature land in 58.

Comment 22

[The 8472]

I think general support for all DOM elements created by content scripts to bypass CSP is dangerous. For example if someone includes some javascript library that is written with the expectation to run in a regular web page in a content script context and that library goes ahead and tries to use <script> tags to load code then you'll suddenly have javascript executing in the untrusted page context.

At least for the specific case of <script> tags any bypass should be opt-in or require extension-specific APIs to work.

I also have concerns about other tags such as <img src="...">, specifically that it does not obscure the included URL. If blob URI + CSP nonce were the norm there would be less information leakage by default.

This is probably not a top concern for most extensions, but since we have no overlays that are invisible to content at least some content-blocking or privacy-focused extensions probably want to reveal as little information as possible to the web content which could report those modifications back to the server.

Comment 24

[Martijn]

Why are addon script inserted as page scripts in the first place? Addons are supposed to be application-wide.

Comment 25

[angelsl]

This bug refers to content scripts which are injected into page context so that the addon can interact with the DOM and page scripts. Not addons themselves.

Comment 26

[Martijn]

Why are they injected into the page? How come an addon can't just interact with a page without modifying it?

Comment 27

[angelsl]

It can. But if you want to inject content into the page, then you're modifying the page. Now what happens if you inject content that loads resources from locations the page's CSP doesn't allow?

Comment 28

[Anthony Lieuallen]

I was pointed here by someone in IRC.  I'm finding that both content scripts registered in `manifest.json` and calls to `tabs.executeScript()` fail for pages with a strict CSP.

For the manifest case:
https://github.com/greasemonkey/greasemonkey/issues/2631
We register a script which `"matches": ["*://*/*.user.js"],` but navigate to a matching URL with a strict CSP, like https://raw.githubusercontent.com/reek/anti-adblock-killer/master/anti-adblock-killer.user.js , and the script does not run.

In the case of `tabs.executeScript()` we get an error that says "Missing host permission for the tab" despite having the "<all_urls>" permission.


So I guess I'm implicitly blocked from injecting content (which I'm not really even trying to do) because I can't even run the script that would be doing such injecting.

Comment 29

[Kris Maglione [:kmag]]

(In reply to Anthony Lieuallen from comment #28)
> I was pointed here by someone in IRC.  I'm finding that both content scripts
> registered in `manifest.json` and calls to `tabs.executeScript()` fail for
> pages with a strict CSP.
> 
> For the manifest case:
> https://github.com/greasemonkey/greasemonkey/issues/2631
> We register a script which `"matches": ["*://*/*.user.js"],` but navigate to
> a matching URL with a strict CSP, like
> https://raw.githubusercontent.com/reek/anti-adblock-killer/master/anti-
> adblock-killer.user.js , and the script does not run.
> 
> In the case of `tabs.executeScript()` we get an error that says "Missing
> host permission for the tab" despite having the "<all_urls>" permission.

CSP doesn't affect content script execution at all. In any case, I can't
reproduce this issue with a simple test extension. Can you provide a complete
testcase?

Comment 30

[Anthony Lieuallen]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #29)
> Can you provide a complete testcase?

See bug #1411641 for more detailed steps including reduced reproduction case.

Comment 31

[marius.santa]

Where can this be tested? Is it implemented somewhere?
Are the tests from bug #1411641 valid? I am asking because of https://bugzilla.mozilla.org/show_bug.cgi?id=1411641#c4.
So far I have https://bugzilla.mozilla.org/show_bug.cgi?id=1400924 and https://bugzilla.mozilla.org/show_bug.cgi?id=615708, are these scenarios valid?
Do you have any other scenarios and web extension examples I can use?

Comment 32

[ggrossetie]

This is also breaking the live preview of the Asciidoctor extension.
Code can be found here: https://github.com/asciidoctor/asciidoctor-chrome-extension/

The following URL should be rendered but nothing happens: https://raw.githubusercontent.com/asciidoctor/asciidoctor/master/README.adoc

Since the CSP on GitHub is really strict, I believe that the content scripts are not executed.

Content-Security-Policy	default-src 'none'; style-src 'unsafe-inline'; sandbox

Comment 33

[Kris Maglione [:kmag]]

(In reply to ggrossetie from comment #32)
> This is also breaking the live preview of the Asciidoctor extension.
> Code can be found here:
> https://github.com/asciidoctor/asciidoctor-chrome-extension/
> 
> The following URL should be rendered but nothing happens:
> https://raw.githubusercontent.com/asciidoctor/asciidoctor/master/README.adoc

This is a mostly unrelated issue. See bug 1411641.

Comment 34

[ggrossetie]

(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #33)
> This is a mostly unrelated issue. See bug 1411641.

Indeed thanks for the pointer.
I've also noticed that my extension is not able to load Google Fonts:

```
Content Security Policy: The page’s settings blocked the loading of a resource at https://fonts.googleapis.com/css?family=Varela+Round|Open+Sans:400italic,700italic,400,700 (“style-src https://gitlab.com 'unsafe-inline' https://gl-static.global.ssl.fastly.net”).
```

The CSP on this page (gitlab.com) is:

```
Content-Security-Policy: object-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https://gl-static.global.ssl.fastly.net https://www.google.com/recaptcha/ https://www.gstatic.com/recaptcha/; style-src 'self' 'unsafe-inline' https://gl-static.global.ssl.fastly.net; img-src * data: blob:; frame-src 'self' https://www.google.com/recaptcha/; frame-ancestors 'self'; connect-src 'self' https://gl-static.global.ssl.fastly.net wss://gitlab.com https://sentry.gitlap.com https://customers.gitlab.com; report-uri https://sentry-infra.gitlap.com/api/3/csp-report/?sentry_key=a664fdde83424b43a991f25fa7c78987
```

Given the error message, we can see that the CSP of the page is applied to the content inserted by my content scripts.

Comment 35

[Kris Maglione [:kmag]]

(In reply to ggrossetie from comment #34)
> (In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're
> blocked) from comment #33)
> > This is a mostly unrelated issue. See bug 1411641.
> 
> Indeed thanks for the pointer.
> I've also noticed that my extension is not able to load Google Fonts:
> 
> ```
> Content Security Policy: The page’s settings blocked the loading of a
> resource at
> https://fonts.googleapis.com/css?family=Varela+Round|Open+Sans:400italic,
> 700italic,400,700 (“style-src https://gitlab.com 'unsafe-inline'
> https://gl-static.global.ssl.fastly.net”).
> ```

This should work if you bundle the CSS in your extension, after bug 1415352 is fixed. The exemption that allows extensions to load blocked stylesheets doesn't extend to content loaded by those stylesheets.

Comment 36

[ggrossetie]

Ok, so in other words, I can't use @import in my stylesheets but I can use url with a "local" path (ie. the font is bundled in my extension), correct ?

Comment 38

[:Harald Kirschner :digitarald]

Per :ckerschb, Bug 965637 should eliminate these kind of problems.

Comment 39

[claudio.vallesi]

Any progress on this? Specifically I find overkill to block unsafe_inline on style-src at all.

Comment 40

[Jules RANDOLPH]

Any updates? I want to run userscripts on a CSP-protected domain with restrictive script-src policies. And I cannot ; it feels like Firefox endorses the site strict policy instead of empowering the user.

Comment 41

[ExE Boss]

(In reply to Jules RANDOLPH from comment #40)
> Any updates? I want to run userscripts on a CSP-protected domain with
> restrictive script-src policies. And I cannot ; it feels like Firefox
> endorses the site strict policy instead of empowering the user.

Can’t you use the the `contentScripts` API¹?

¹ https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/contentScripts

Comment 42

[Jules RANDOLPH]

(In reply to ExE Boss from comment #41)
> (In reply to Jules RANDOLPH from comment #40)
> > Any updates? I want to run userscripts on a CSP-protected domain with
> > restrictive script-src policies. And I cannot ; it feels like Firefox
> > endorses the site strict policy instead of empowering the user.
> 
> Can’t you use the the `contentScripts` API¹?
> 
> ¹
> https://developer.mozilla.org/docs/Mozilla/Add-ons/WebExtensions/API/
> contentScripts

Thanks, I will ping Tampermonkey authors.

Comment 43

[Julien Wajsberg [:julienw]]

This is still breaking react and redux devtools.

Comment 44

[danshumway]

> Can’t you use the the `contentScripts` API¹?

My understanding is that contentScripts don't have the same access to objects like ``unsafeWindow``. I'm still looking into the exact details for everything, so it could be that there's a secondary privilege or alternate approach that I'm missing.

Assuming that there isn't, currently this is blocking an extension I use, ViolentMonkey, from allowing scripts to run on sites like Github and Twitter.

I understand and support the security side of things, but it feels like (especially in the case of Twitter) their use of CSP is probably not just about security, but also somewhat about them making it harder for any of their users to significantly alter the page. I would support some kind of security mechanism that didn't allow website operators to decide to hamper a user's ability to build webextensions for that domain that leverage more powerful extension APIs.

Comment 45

[Rob Wu [:robwu]]

(In reply to danshumway from comment #44)
> > Can’t you use the the `contentScripts` API¹?
> 
> My understanding is that contentScripts don't have the same access to
> objects like ``unsafeWindow``.

See https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Sharing_objects_with_page_scripts

Comment 46

[danshumway]

(In reply to Rob Wu [:robwu] from comment #45)
> See
> https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/
> Sharing_objects_with_page_scripts

Thanks, will take a look and do some additional research.

Comment 47

[:Harald Kirschner :digitarald]

For reference, the WebHint devtools extensions has to add a CSP-quirks detection to work around the silent failing that content script CSP issues lead to: https://github.com/webhintio/hint/issues/2708

Comment 48

[Tanner Stirrat]

Confirming that React and Redux Devtools are still broken.

Comment 49

[Tom S. (please needinfo tschuster)]

I am going to look into some of those issues. I really want to avoid extensions having to modify the CSP header, recently I heard that we are even removing extensions from AMO for doing that.

I am aware of at least one issue, with <script> and innerText while src works.

Comment 50

[Caleb Maclennan]

The collateral damage list for this not being fixed is growing. CSP is a reasonable thing for sites to implement but without the ability to override it, end user's are starting to be the loosers.

In my case Firenvim doesn't work on Stack Overflow. I can't really blame Stack Exchange for wanting to lock down their pages as best they can, but the reason I use Firefox is that I expect it to be on my side and do what I want. That essential freedom is what's at stake here, I can't even make my computer do something locally that I want it to do.

Comment 51

[Rob Wu [:robwu]]

@caleb After looking at you repo, it seems that you're claiming that WebSockets are subjected to the page's CSP. If this is the case, then that's a bug that we'd like to fix. Please file a new bug report with a test case to reproduce the problem (if you cc me on it, I will link other relevant bugs to it).

Side note: A work-around is to create the WebSocket connection from a background page (or if you really want to tie it to the page's lifetime, through an iframe with an extension page in the current document).

Comment 52

[glacambre]

or if you really want to tie it to the page's lifetime, through an iframe with an extension page in the current document

That's already what firenvim does. However, Content Security Policy: Upgrading insecure request ‘ws://127.0.0.1:38779/4030261693’ to use ‘wss’ is still logged in the console. Is there something I can do to work around that?

Comment 53

[Alex Haan]

(In reply to glacambre from comment #52)

However, Content Security Policy: Upgrading insecure request ‘ws://127.0.0.1:38779/4030261693’ to use ‘wss’ is still logged in the console. Is there something I can do to work around that?

That's a different limitation. In the past, for some personal userscript talking to a little Python program I wrote to run on my PC, I 'simply' made it run wss instead of ws.

I have no experience with firenvim though. So I can't give recommendations on that.

Comment 54

[glacambre]

That's a different limitation

Are you saying that this CSP warning, that only happens on pages that use Content-Security-Policy: upgrade-insecure-requests and that (IMO) has no reason to apply to an iframe the document of which is located in webextension storage, is not covered by this bug? If yes, is there another bugzilla ticket that covers this bug, or should I open one?

Comment 55

[Rob Wu [:robwu]]

(In reply to glacambre from comment #54)

That's a different limitation

Are you saying that this CSP warning, that only happens on pages that use Content-Security-Policy: upgrade-insecure-requests and that (IMO) has no reason to apply to an iframe the document of which is located in webextension storage, is not covered by this bug? If yes, is there another bugzilla ticket that covers this bug, or should I open one?

This bug is a metabug. If you have specific test cases, please file a new bug and mark it as a blocker of this bug if you can.

Comment 56

[Simon Lydell]

Use case: Extensions that can run on any page and inject UI inside a ShadowRoot with a <style> tag in there. I’m using a <style> tag because the user can customize the appearance of the UI. I currently ship a somewhat slow and sucky home-made CSS engine as a workaround on pages with strict CSP (using regex, Element.matches() and Element.style.setProperty()): https://github.com/lydell/LinkHints/blob/6f708e19456fc3e5f0d1a388a2adcf1ffaff1c97/src/renderer/css.js

Comment 57

[Shane Hughes [:aminomancer]]

here's the simplest test case I could come up with, should take like 30 seconds to set up. at least for me, this is usually resulting in a silent failure e.g. on csp sandbox pages.

manifest.json:
{
"manifest_version": 2,
"name": "Dark Plaintext",
"version": "1.0",
"description": "",
"content_scripts": [
{
"matches": [
"<all_urls>"
],
"js": [
"injector.js"
],
"run_at": "document_end",
"all_frames": true,
"match_about_blank": true
}
],
"permissions": [
"tabs",
"<all_urls>"
]
}

injector.js can be anything but this is what i was personally using to test it, along with web_accessible_resources: style.css in the manifest. if it weren't for the csp thing, i'm pretty sure this tiny snippet plus css rules for body, ::-moz-selection, would be sufficient to implement "dark mode" on any plaintext page.
(function () {
var sheetArr = [];
console.log('running injector');
for (let i = 0; i < document.styleSheets.length; i++) {
sheetArr.push(document.styleSheets[i]);
console.log('added sheet to array');
};

function checkPlain(sheet) {
    console.log('checking sheet');
    return /plaintext\.css$/i.test(sheet.href) && sheet.disabled === false;
};
if (sheetArr.some(checkPlain)) {
    console.log('at least one plain sheet found');
    var sheetLink = document.createElement("link");
    sheetLink.href = chrome.extension.getURL("style.css");
    sheetLink.type = "text/css";
    sheetLink.rel = "stylesheet";
    (document.head || document.documentElement).appendChild(sheetLink);
};

})();

this one's kinda aggravating me because i don't know of any other way to do this. the only things i can think of are to disable CSP altogether, or (maybe) to try implementing pseudo-content scripts from some kind of globally scoped userchrome.js loader and an autoconfig setup to load that. which seems really outdated and sloppy, using event listeners to see when a page has loaded instead of webextensions APIs, and registering the css as an agent sheet to bypass the CSP. i tried something in between, like injecting the CSS rules into javascript objects instead of making a link DOM object, but the CSP blocks that too. maybe i'm missing something super obvious so hopefully someone can let me know if there really is a way to do this without turning off CSP altogether. it seems crazy to me that there aren't some more granular prefs for overriding CSP. like at least being able to turn off the sandbox restriction would be nice, but it would be ideal if you could keep the all the restrictions intact but allow extensions to bypass any of them. even better, allow extensions to bypass restrictions arbitrarily, provided they request a certain new permission. call it override_csp or something

Comment 58

[[e-mail]]

(In reply to shmediaproductions from comment #57)

        "js": [
            "injector.js"

Why don't you instead use "css": [ "style.css" ] in your manifest?

Comment 59

[Shane Hughes [:aminomancer]]

(In reply to [e-mail] from comment #58)

(In reply to shmediaproductions from comment #57)

        "js": [
            "injector.js"

Why don't you instead use "css": [ "style.css" ] in your manifest?

same difference, script or stylesheet, the src is blocked. the only way around it seems to be disabling CSP. I spent a couple weeks working on an extension that disables CSP for pages based on the stylesheets they have loaded, with that webRequest.onHeadersReceived. didn't run smoothly though, can't seem to verify plaintext.css's presence in the doc before the headers have gone through. so it wouldn't load stylesheet until half a second after the page loaded, which is ugly. I deleted it, but i do remember the methods I used. it was similar to https://github.com/PhilGrayson/chrome-csp-disable/blob/master/background.js and https://github.com/Rufflewind/chrome_cspmod/blob/master/src/background.js

Comment 60

[Shane Hughes [:aminomancer]]

also just thought I'd mention, it blocks everything the user could conceivably do to modify the style except for console commands made after the page load from within the document scope. so rules in a userContent.css file are ignored. I also tried using the nsI stylesheet service to load + register the stylesheet as an agent sheet and again as an author sheet, but this loads the rules as inline style and the CSP naturally blocks inline styles. same goes for createProcessingInstruction('xml-stylesheet'...) unfortunately. I tried to use constructable stylesheets a while ago, and might have done something wrong, but at the time it seemed like I did it correctly but it never showed up in the list. not unless I did it with the console, but a browser extension can't have that level of access.

in the document scope it just gets blocked, and using the webRequest API it can't seem to access the important info (the lack of any stylesheet requests, or the presence of plaintext.css after response headers finish) before the page loads. I might have messed up my script though, I did essentially base it on chrome extensions and I don't know the extent to which they're really different. where necessary, I substituted 'browser' for 'chrome' and storage.local for storage.sync, but still couldn't seem to get it to recognize that these plaintext docs were not requesting any stylesheets until after the page was idle. I did also run up against the application cache service worker problem where headers are not sent in the first place bc the page is cached, but I copied a solution for that from phil grayson's extension and it worked. so I don't think that's the issue messing up the sequencing.

another weird thing I ran into was an error handler that says "'urls' member of MozRequestFilter does not implement interface MatchPatternSet." this in response to onHeadersReceived trying to evaluate urls. the thing is, I didn't even need to use a match pattern. it gave me that response even when the urls field was blank. maybe this is supposed to request another API I'm not aware of. I went through the webRequest files in the source code to see if I was missing something but I don't think so.

Comment 61

[Shane Hughes [:aminomancer]]

the webRequest stuff has to run as a background script apparently, but the only way I know of to immediately check the stylesheets that actually worked is running in the scope of the document, like in a content script. so maybe I was supposed to try to set up a messaging interface between a background script checking headers and a content script checking stylesheets. but I couldn't find any way to set manifest.json that would get the content script to load on plaintext files. dark reader and other similar extensions get blocked too, though they don't know it. when you load a local page or chrome UI page, those extensions will say "blocked on this domain" or something, not for CSP reasons but bc of webextensions permissions, but injecting content scripts or stylesheets in a plain text file on raw.githubusercontent.com will be blocked for CSP reasons, but the extension won't show any message about it. and if CSP is disabled, the extension will work as normal.

so for me it seems like any method I could use ultimately runs up against the brick wall that extensions can't get into that document scope without loading a content script, but they can't load a content script while the CSP rules are set to defaults. so any script injected into the document context would have to be done dynamically, from a background script, but I don't know how to do that with webextensions. I tried doing it with a userscript and alice0775's autoconfig loader a long time ago but I either couldn't figure out how to traverse into the browser document, or couldn't figure out how to set up reliable event listeners to check every page load, tab change etc.

Comment 62

[juha.kalliokoski]

Hi, what's the situation with this? This thing causes issues e.g. for a popular browser addon called uBlock Origin. It can't in some cases override website's policies.

Some related issues:
https://github.com/DandelionSprout/adfilt/discussions/642
https://github.com/uBlockOrigin/uBlock-issues/issues/2079

Comment 63

[juha.kalliokoski]

Here uBO dev explains the issue https://github.com/uBlockOrigin/uBlock-issues/issues/2079#issuecomment-1088678416 (linking more directly into a comment in the second link).

Comment 65

[Kai Mast]

This also seems to break MetaMask. Any hope to get this fixed?

Comment 66

[fabrizio.audisio]

This bug is 7 years old. It really needs to be fixed please. Among other plugins, it blocks MetaMask on any dapp using CSP. It's a deal blocker for users that want to use Firefox and not Chrome or Safari.

Comment 67

[Julien Palard]

I feel like this is a privacy issue:

if the CSP report varies enough¹ from an extension to another, Cloudflare (that handles most of CSP reports) can produce a list of (ip, user-agent, extention), which is concerning from a privacy point of view. It's a bigger privacy concern knowing that Privacy Badger is currently one of those extensions.

[1]: I've seen the report vary from an extension to another, but I did not studied if it's enough to recognize them unambiguously

I've curled a few .fr domains from the AFNIC opendata and 73 out of 80 domains that have CSP reporting uses Cloudflare.

For the curious, I used:

cut -d';' -f1 202302_OPENDATA_A-NomsDeDomaineEnPointFr.csv  | while read -r line; do HAS_REPORT="$(curl -m 3 -I "$line" | grep -i 'reporting-endpoints\|report-to\|report-uri')"; if [[ -n "$HAS_REPORT" ]]; then printf "%s\n%s\n\n" "$line" "$HAS_REPORT"; fi; done | tee reports

Comment 68

[Kestrel]

(In reply to Julien Palard from comment #67)

I feel like this is a privacy issue

Bug 1588957 covers the privacy issue of extension CSP reports. The reports do not include extension ID since Bug 1705523. uBlock Origin blocks all CSP reports and is superior to Privacy Badger in every way (dynamic blocking creates more privacy issues).

Comment 69

[Matt]

I've seen mention upthread of this causing an issue in the React Dev Tools, but it looks like nobody's linked it so adding that to the thread. It causes them to fail to load in many instances that work for Chrome.

https://github.com/facebook/react/issues/17997

Comment 70

[j-d-salinger]

Dudes, I tried to get Firefox to stop blocking my locally hosted website with these ridiculously verbose CSP headers that I found on stackoverflow in Firefox 101 (or whatever the latest Debian bullseye release is for firefox-esr). It worked in Chrome but not Firefox. I literally just wanted to test my WEBSITE, instead I had to spend HOURS figuring out why Firefox (only available on Debian) wasn't letting the page go through. Guess what - I still don't know the correct header to get Firefox to ignore CSP.

Why don't you just allow people to disable CSP??? Through ABOUT:CONFIG???? I can't find the same issue, but there's literally a guy who MUST be a Google-Chrome-hired saboteur in one of these similar bugs saying that he sees "no possible situation" in which developers would want to disable CSP. He won't even allow the option in the developer edition of FIrefox.

Huh?? Are y'all on drugs??? Just add the setting back!!! It's literally all over the web as the solution, it's still in the ABOUT:CONFIG SETTINGS, BUT IT DOESN'T FUNCTION!!!

Comment 71

[Julius]

(In reply to j-d-salinger from comment #70)

Just add the setting back!!! It's literally all over the web as the solution, it's still in the ABOUT:CONFIG SETTINGS, BUT IT DOESN'T FUNCTION!!!

Did the setting get removed?
If that's the case, I think you should make a new, separate bug about that.

Comment 74

[Nick Carr]

I won't do that, because of the way you replied. (In reply to Julius from comment #71)

(In reply to j-d-salinger from comment #70)

Just add the setting back!!! It's literally all over the web as the solution, it's still in the ABOUT:CONFIG SETTINGS, BUT IT DOESN'T FUNCTION!!!

Did the setting get removed?
If that's the case, I think you should make a new, separate bug about that.

The setting is there but does nothing. Why can't I load 4 IP cameras into an HTML table on a single page anymore? Oh, because of CSP. Let me disable it.... Hmm, doesn't work!

Also, your question is dumb? I made an incredible short comment: The setting is there, but does nothing. So your question "was the setting removed?" is highly offensive.

Comment 75

[Nick Carr]

No matter what the CSP is for the IP Camera hosts!!!! Nao funciona!!!!

Comment 76

[Andre Klapper]

@Nick Carr: Either please read and follow https://bugzilla.mozilla.org/page.cgi?id=etiquette.html , or spend your time somewhere else. Thanks.

Comment 77

[david]

Is it to possible to get this prioritized by someone on the Extension team? If not, could someone from the team possibly point out specific files/directories in the source code that might be involved so someone from the community might be tempted to tackle it?

Comment 78

[Rob Wu [:robwu]]

This is a metabug covering many issues. It is not clear what you are referring to.

If you are looking for a way that inline <script> elements can execute in the page's context independently of the web page's CSP, then that is covered by bug 1446231. That bug is tracked but not actively worked on. Note that in Chrome, MV3 content scripts with inline script sources are blocked too.

For use cases where extensions want to run some known scripts in the page's context, extensions can already specify the world option set to "MAIN", when they want to run content scripts, whether through static content_scripts in manifest.json, dynamic scripts through scripting.executeScript, or declarative content scripts through scripting.registerContentScripts.

Comment 79

[david]

(In reply to Rob Wu [:robwu] from comment #78)

This is a metabug covering many issues. It is not clear what you are referring to.

If you are looking for a way that inline <script> elements can execute in the page's context independently of the web page's CSP, then that is covered by bug 1446231. That bug is tracked but not actively worked on. Note that in Chrome, MV3 content scripts with inline script sources are blocked too.

For use cases where extensions want to run some known scripts in the page's context, extensions can already specify the world option set to "MAIN", when they want to run content scripts, whether through static content_scripts in manifest.json, dynamic scripts through scripting.executeScript, or declarative content scripts through scripting.registerContentScripts.

Thanks. bug 1446231 is slightly more narrowed; though my Spidey Sense is telling me fixing that one correctly fixes this "meta" bug correctly. I'll comment there.

Comment 80

[david]

Couple of updates:

We shipped a workaround that modified the CSP header (we build for MV2 still) to allow our own script to be injected into CSP protected pages.

Unfortunately we ran into two problems after shipping it:

1. we got the CSP modification code wrong and managed to break most of the Internet for our users (we shipped it with a User Setting so users were able to fix it easily).
2. Mozilla actually removed our CSP-fix release from the extension store because they said modifying the CSP header is not allowed (there are many extensions published that do modify the CSP header, so it wasn't clear why they are allow but we aren't).

So it is possible to modify a strict CSP header in MV2 builds if you have blocking permissions in your manifest. However, FF may not let you publish it (or will remove the release after publishing).

There is another workaround that works around CSP issues 100% of the time, and it was written by Mozilla's very own Tom Schuster! It works great in situations where the script being injected doesn't need to run before other JavaScript on the page.

This doesn't work in CSP protected pages:

const script = document.createElement("script");
script.textContent = "console.log(123)";
document.documentElement.append(script);
console.log(456);
// logs: 123, then 456

This next code works in CSP protectd pages, but logs in the wrong order:

const script = document.createElement("script");
const blob = new Blob(["console.log(123)"], {type:"text/javascript"});
const url = URL.createObjectURL(blob);
script.src= url
document.documentElement.append(script);
console.log(456);
// logs:  456, then 123

So thank you, Tom, for pointing me to this workaround. It was very promising, but unfortunately it won't work for us. If you have any other ideas I'd love to give them a try!

Comment 81

[Julien Wajsberg [:julienw]]

Make sure the script isn't async. I think it's async by default, so it is asynchronously fetched and evaluated.
Set script.async=false before appending it.

Comment 82

[swleefers]

Thank you all for working on work-arounds. On outlook.live.com, both lines are printed to console, though still in the wrong order even with script.async=false

But neither version works works for me on gmail.com, I get an error and "123" never appears.

Comment 83

[david]

(In reply to Julien Wajsberg [:julienw] from comment #81)

Make sure the script isn't async. I think it's async by default, so it is asynchronously fetched and evaluated.
Set script.async=false before appending it.

That doesn't work, unfortunately. <script> elements that are not "parser inserted" have their force async flag set to true.

Comment 84

[david]

(In reply to swleefers from comment #82)

Thank you all for working on work-arounds. On outlook.live.com, both lines are printed to console, though still in the wrong order even with script.async=false

But neither version works works for me on gmail.com, I get an error and "123" never appears.

Are you just running the script in the console, or actually with you application?

If its in the console and the error is "redeclaration of const script", it is just because in my two examples above I used the same const names, and you can't run the code twice without refreshing in between.

Putting the examples in their own block scope should work:

{
const script = document.createElement("script");
const blob = new Blob(["console.log(123)"], {type:"text/javascript"});
const url = URL.createObjectURL(blob);
script.src= url
document.documentElement.append(script);
console.log(456);
// logs:  456, 123
}

I've tested gmail using the Blob workaround and it worked fine (it just executed too late for my use case)

Comment 85

[swleefers]

(In reply to david from comment #84)

Ah, no, I removed the consts before trying. Perhaps this is not the right place for this, but this is what it looks like:

https://i.imgur.com/qJ3IC8j.jpeg

Perhaps this is also dependent on certain browser settings? Though it was in a mostly empty profile with all extensions disabled.

Comment 86

[david]

(In reply to swleefers from comment #85)

(In reply to david from comment #84)

Ah, no, I removed the consts before trying. Perhaps this is not the right place for this, but this is what it looks like:

https://i.imgur.com/qJ3IC8j.jpeg

Perhaps this is also dependent on certain browser settings? Though it was in a mostly empty profile with all extensions disabled.

Interesting, try it in an extension's content script.

Comment 87

[Tom Schuster]

Can we please not have these discussions in a meta bug with over 100 subscribers? Thank you!

Comment 88

[Tom Schuster]

bug 1446231 is about inline <script> not bypassing CSP.