When an extension does not have host permissions in a content script, it should fall back to CORS (i.e. send a request and proceed with the request if the requested resource includes CORS headers; the browser should add the "Origin" request header). Chrome does this, but Firefox does not (tested Firefox 56 until 73.0a1).

STR:

1. Create a directory with the following two files:

manifest.json:

{ "name": "w/o perms", "manifest_version": 2, "version": 1,
  "content_scripts": [{"js": ["contentscript.js"], "matches":["*://example.com/*"] } ]}

contentscript.js:

var x = new XMLHttpRequest();
x.open("GET", "https://cors-anywhere.herokuapp.com/example.com");
x.onload = x.onerror = e => console.log(e.type);
x.send();

2. Load the directory as an extension via about:debugging
3. Visit https://example.com
4. Open the tab's console and look at the result.

Expected:

• "load"

Actual:

• "error"
• If I open the global browser's console and enable content logging, I see the following error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cors-anywhere.herokuapp.com/example.com. (Reason: CORS header ‘Origin’ cannot be added).

The header is not added because the content script has an expanded principal: https://searchfox.org/mozilla-central/rev/b243debf6235b050b42fd2eb615fdc729636ca6b/netwerk/protocol/http/nsCORSListenerProxy.cpp#947-949

We should probably fall back to the page's origin, or at least the null origin.

Extensions can work around this bug by either requesting the correct permissions, or by using the background page to send the request.

We should probably use PrincipalToInherit for the origin header principal, or at least the expanded principal downgrade logic that it uses.

The priority flag is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Confirmed this issue with Firefox 78.

I was able to make cross-domain XHR requests work with Chrome but they fail with Firefox.

I'm using "permissions" to work it around, which is far from being a real solution for the problem:
https://github.com/ckeditor/github-writer/blob/4be6c72519869029faff28b6f19a4f381c951e0a/src/extension/manifest.json#L9-L14

As a side-note, Chrome is still in the process of aligning their CORs behavior for extensions, but most of the changes already landed current versions. More info can be found here:
https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

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

We should probably fall back to the page's origin, or at least the null origin.

Be careful to avoid making bug 1405971 worse.

Extensions can work around this bug by either requesting the correct permissions

which wouldn't work if bug 1578405 were to be implemented.

or by using the background page to send the request.

which doesn't play well with container tabs, bug 1670278