Cross-Origin requests in content scripts will soon be disallowed

2,170 views
Skip to first unread message

ForeverNewbieChromeDev

unread,
Mar 19, 2019, 9:42:53 PM3/19/19
to Chromium Extensions
I was reading this latest update from Chrome.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


Our chrome extension is heavily dependent on outside request from Google Slide. We also use firebase in our content script. The purpose of using firebase within the content script is that Chrome messaging (background to content-script vise-versa) is very limited when it comes to passing the data. What we are passing is large data (audio files). What would be an alternative way to handle this issue.

PhistucK

unread,
Mar 20, 2019, 4:45:56 AM3/20/19
to ForeverNewbieChromeDev, Chromium Extensions
Can you add CORS support to your backend?
If Firebase is the backend and it does not allow CORS out of the box, perhaps there is a setting that allows CORS or allows CORS for certain origins.

☆PhistucK


--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/f0688a6d-863a-4665-a825-d881853b563f%40chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

ForeverNewbieChromeDev

unread,
Mar 20, 2019, 6:06:26 AM3/20/19
to Chromium Extensions, dolf.al...@gmail.com
As far as I know, firebase does support CORS. You can call it anywhere. The problem here is Google Chrome is blocking it if your request is coming from content script. The ideal setup is firebase should be working in the background but there is also a limitation for that setup, like in our setup we allow users to upload audio from google slide. Chrome extension does not support passing large data from content script to background. The only way is to instantiate a Firebase connection within the content script and from there you can communicate to firebase but due to new restriction of Google Chrome extension this action is already forbidden.


On Wednesday, March 20, 2019 at 4:45:56 PM UTC+8, PhistucK wrote:
Can you add CORS support to your backend?
If Firebase is the backend and it does not allow CORS out of the box, perhaps there is a setting that allows CORS or allows CORS for certain origins.

☆PhistucK


On Wed, Mar 20, 2019 at 3:43 AM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
I was reading this latest update from Chrome.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


Our chrome extension is heavily dependent on outside request from Google Slide. We also use firebase in our content script. The purpose of using firebase within the content script is that Chrome messaging (background to content-script vise-versa) is very limited when it comes to passing the data. What we are passing is large data (audio files). What would be an alternative way to handle this issue.

--
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-extensions+unsub...@chromium.org.

PhistucK

unread,
Mar 20, 2019, 6:12:59 AM3/20/19
to ForeverNewbieChromeDev, Chromium Extensions
Chrome is not blocking cross origin requests that are allowed by CORS, even in content scripts (otherwise they would be more limited than regular websites, which makes no sense).
Are you seeing CORS headers and blocked responses?

☆PhistucK


On Wed, Mar 20, 2019 at 12:06 PM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
As far as I know, firebase does support CORS. You can call it anywhere. The problem here is Google Chrome is blocking it if your request is coming from content script. The ideal setup is firebase should be working in the background but there is also a limitation for that setup, like in our setup we allow users to upload audio from google slide. Chrome extension does not support passing large data from content script to background. The only way is to instantiate a Firebase connection within the content script and from there you can communicate to firebase but due to new restriction of Google Chrome extension this action is already forbidden.

On Wednesday, March 20, 2019 at 4:45:56 PM UTC+8, PhistucK wrote:
Can you add CORS support to your backend?
If Firebase is the backend and it does not allow CORS out of the box, perhaps there is a setting that allows CORS or allows CORS for certain origins.

☆PhistucK


On Wed, Mar 20, 2019 at 3:43 AM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
I was reading this latest update from Chrome.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


Our chrome extension is heavily dependent on outside request from Google Slide. We also use firebase in our content script. The purpose of using firebase within the content script is that Chrome messaging (background to content-script vise-versa) is very limited when it comes to passing the data. What we are passing is large data (audio files). What would be an alternative way to handle this issue.

--
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.

--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/76833089-c76d-4731-a914-67bb16865c5f%40chromium.org.

ForeverNewbieChromeDev

unread,
Mar 20, 2019, 10:42:26 AM3/20/19
to Chromium Extensions
Yes they are blocking it based on their latest release note. 

Read this: 
https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


On Wednesday, March 20, 2019 at 6:12:59 PM UTC+8, PhistucK wrote:
Chrome is not blocking cross origin requests that are allowed by CORS, even in content scripts (otherwise they would be more limited than regular websites, which makes no sense).
Are you seeing CORS headers and blocked responses?

☆PhistucK


On Wed, Mar 20, 2019 at 12:06 PM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
As far as I know, firebase does support CORS. You can call it anywhere. The problem here is Google Chrome is blocking it if your request is coming from content script. The ideal setup is firebase should be working in the background but there is also a limitation for that setup, like in our setup we allow users to upload audio from google slide. Chrome extension does not support passing large data from content script to background. The only way is to instantiate a Firebase connection within the content script and from there you can communicate to firebase but due to new restriction of Google Chrome extension this action is already forbidden.

On Wednesday, March 20, 2019 at 4:45:56 PM UTC+8, PhistucK wrote:
Can you add CORS support to your backend?
If Firebase is the backend and it does not allow CORS out of the box, perhaps there is a setting that allows CORS or allows CORS for certain origins.

☆PhistucK


On Wed, Mar 20, 2019 at 3:43 AM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
I was reading this latest update from Chrome.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


Our chrome extension is heavily dependent on outside request from Google Slide. We also use firebase in our content script. The purpose of using firebase within the content script is that Chrome messaging (background to content-script vise-versa) is very limited when it comes to passing the data. What we are passing is large data (audio files). What would be an alternative way to handle this issue.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

PhistucK

unread,
Mar 20, 2019, 10:53:37 AM3/20/19
to ForeverNewbieChromeDev, Chromium Extensions
They are blocking whatever a regular website cannot do. CORS approved requests should be supported. If you see an issue with such requests, it is either a server bug, or a browser bug.
From the link you posted (with my emphasis) -
"To mitigate these concerns, future versions of Chrome will limit content scripts to the same fetches that the page itself can perform."

☆PhistucK


On Wed, Mar 20, 2019 at 4:42 PM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
Yes they are blocking it based on their latest release note. 

Read this: 
https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

On Wednesday, March 20, 2019 at 6:12:59 PM UTC+8, PhistucK wrote:
Chrome is not blocking cross origin requests that are allowed by CORS, even in content scripts (otherwise they would be more limited than regular websites, which makes no sense).
Are you seeing CORS headers and blocked responses?

☆PhistucK


On Wed, Mar 20, 2019 at 12:06 PM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
As far as I know, firebase does support CORS. You can call it anywhere. The problem here is Google Chrome is blocking it if your request is coming from content script. The ideal setup is firebase should be working in the background but there is also a limitation for that setup, like in our setup we allow users to upload audio from google slide. Chrome extension does not support passing large data from content script to background. The only way is to instantiate a Firebase connection within the content script and from there you can communicate to firebase but due to new restriction of Google Chrome extension this action is already forbidden.

On Wednesday, March 20, 2019 at 4:45:56 PM UTC+8, PhistucK wrote:
Can you add CORS support to your backend?
If Firebase is the backend and it does not allow CORS out of the box, perhaps there is a setting that allows CORS or allows CORS for certain origins.

☆PhistucK


On Wed, Mar 20, 2019 at 3:43 AM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
I was reading this latest update from Chrome.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


Our chrome extension is heavily dependent on outside request from Google Slide. We also use firebase in our content script. The purpose of using firebase within the content script is that Chrome messaging (background to content-script vise-versa) is very limited when it comes to passing the data. What we are passing is large data (audio files). What would be an alternative way to handle this issue.

--
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.

--
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.

--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/4676314a-d143-45c6-a9b5-d8f261e286d3%40chromium.org.

PhistucK

unread,
Mar 20, 2019, 11:03:45 AM3/20/19
to randolf alegre, Chromium Extensions
See my emphasis on your emphasis (with ******) :)
"these" means, the cross origin requests that they described earlier - the ones that worked only if you listed their origins in the permissions of the extension.

Also, another emphasis (*-*-*-*-*-*-*-) that says content scripts can do the same things a regular website can.

☆PhistucK


On Wed, Mar 20, 2019 at 4:56 PM randolf alegre <dolf.al...@gmail.com> wrote:
What does this mean?

"When web pages request cross-origin data with fetch or XHR APIs, the response is denied unless CORS headers allow it.  In contrast, extension content scripts have traditionally been able to fetch cross-origin data from any origins listed in their extension's permissions, regardless of the origin that the content script is running within.  As part of a broader Extension Manifest V3 effort to improve extension security, privacy, and performance, ******these****** cross-origin requests in content scripts will soon be disallowed.  *-*-*-*-*-*-*-Instead, content scripts will be subject to the same request rules as the page they are running within*-*-*-*-*-*-*-.  Extension pages, such as background pages, popups, or options pages, are unaffected by this change and will continue to be allowed to bypass CORS for cross-origin requests as they do today.

See two emphasis instances above.

 

Our data shows that most extensions will not be affected by this change.  However, any content scripts that do need to make cross-origin requests can do so via an extension background page, which can relay the data to the content script.  We have a migration plan below to help affected extension developers make the transition to the new model."

holo...@gmail.com

unread,
Mar 20, 2019, 11:05:15 AM3/20/19
to Chromium Extensions, dolf.al...@gmail.com
We had to move all CORS-violating requests from content.js to background.js and that fixed the issue. You may already know this, but if you need to make a cross-origin call, use messaging:

Use this in content:

chrome.runtime.sendMessage

And this in background:

chrome.runtime.onMessage.addListener

Then make the call in the background. Then do the reverse to send the response back.


On Wednesday, March 20, 2019 at 4:45:56 AM UTC-4, PhistucK wrote:
Can you add CORS support to your backend?
If Firebase is the backend and it does not allow CORS out of the box, perhaps there is a setting that allows CORS or allows CORS for certain origins.

☆PhistucK


On Wed, Mar 20, 2019 at 3:43 AM ForeverNewbieChromeDev <dolf.al...@gmail.com> wrote:
I was reading this latest update from Chrome.

https://www.chromium.org/Home/chromium-security/extension-content-script-fetches


Our chrome extension is heavily dependent on outside request from Google Slide. We also use firebase in our content script. The purpose of using firebase within the content script is that Chrome messaging (background to content-script vise-versa) is very limited when it comes to passing the data. What we are passing is large data (audio files). What would be an alternative way to handle this issue.

--
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-extensions+unsub...@chromium.org.

ForeverNewbieChromeDev

unread,
Mar 20, 2019, 11:11:27 AM3/20/19
to Chromium Extensions
Here is the feature that we are building: Users can upload audio from the content script. Message passing from Content Script to background is limited since it only accepts JSON Object. Now, for our backend we use Firebase. Uploading of audios are done in the content script.

ForeverNewbieChromeDev

unread,
Mar 20, 2019, 11:13:24 AM3/20/19
to Chromium Extensions
Here is the feature that we are building: Users can upload audio from the content script. Message passing from Content Script to background is limited since it only accepts JSON Object. Now, for our backend we use Firebase. Uploading of audios are done in the content script.  Does this mean we are limited or completely we cannot implement this feature due to their new implementation?
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

PhistucK

unread,
Mar 20, 2019, 11:15:47 AM3/20/19
to ForeverNewbieChromeDev, Chromium Extensions
Again, does it work in a regular website?
If it does and it does not work in content scripts, then, assuming the Origin HTTP request header is not different (for example, in content scripts, it may be chrome-extensions://..., I do not remember) and assuming CORS approves the request, then this is probably a Chrome bug.

☆PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

--
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.

--
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.

--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/d5246e43-0cf3-4979-b52e-32accdc90411%40chromium.org.

Ian VanSchooten

unread,
Mar 20, 2019, 9:17:53 PM3/20/19
to Chromium Extensions, dolf.al...@gmail.com
I believe that the chrome bug is https://bugs.chromium.org/p/chromium/issues/detail?id=920638.  It sounds like CORS from content scripts is not working correctly.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

--
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-extensions+unsub...@chromium.org.

PhistucK

unread,
Mar 21, 2019, 5:16:38 AM3/21/19
to ForeverNewbieChromeDev, sim...@chromium.org, Chromium Extensions, Ian VanSchooten
Thank you, Ian! Bad news, but the situation is at least clearer. I am surprised they do not consider this a first priority regression (I added Simeon to follow up, though).

Unfortunately, the original poster should ask to be on the allow-list at the moment, because the upcoming solution will not be implemented in the short term. :(
Please, use the "file a bug" link in "4. Keep in Touch if Allowlisting is Needed" of https://www.chromium.org/Home/chromium-security/extension-content-script-fetches for that.

☆PhistucK


To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

--
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.

--
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.

--
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.

--
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 post to this group, send email to chromium-...@chromium.org.
Visit this group at https://groups.google.com/a/chromium.org/group/chromium-extensions/.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/a578f886-c345-4fb1-904a-f22a8aada233%40chromium.org.

Dinesh Bhosale

unread,
Apr 28, 2019, 2:20:58 PM4/28/19
to Chromium Extensions, dolf.al...@gmail.com
Get requests sent from background page do not have "Origin" header, so they succeed.
Post requests have "Origin" header, so they fail.

We were able to resolve this issue by using 'webRequests' api but it appears it won't be able to remove "Origin" header to make post requests succeed (when manifest version 3 is enforced) then how should a developer implement this functionality to make their extension future proof?

Example:
manifest.json
```
{
  "background": {
    "page": "background.html"
  },
  "browser_action": {
    "default_title": "XHR Test"
  },
  "description": "Cross origin post requests are not working from background pages.",
  "name": "XHR Test",
  "manifest_version": 2,
  "short_name": "TFF",
  "permissions": [
    "*://*.instagram.com/*"
  ],
  "version": "0.1",
  "content_security_policy": "script-src 'self' https://ssl.google-analytics.com; object-src 'self'"
}
```


background.html:

```
<html>
<head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <script src="background.js"></script>
</head>
<body>

</body>
</html>
```

background.js:

```
function testGet() {
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function () {
        if (xhr.readyState == XMLHttpRequest.DONE) {

        }
    };
    xhr.open('GET', 'https://www.instagram.com', true);
    xhr.send(null);
}

function testPost() {
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function () {
        if (xhr.readyState == XMLHttpRequest.DONE) {

        }
    };
    xhr.open('POST', 'https://www.instagram.com', true);
    xhr.send(null);
}

testGet();
testPost();
```

Changes were made to content scripts, these changes have forced us to use the background page instead:

But background pages are sending incorrect "Origin" header causing requests to fail, only solution we have at the moment is to use the "webRequest" api but we don't want to use "webRequest" api as it is getting removed in the upcoming versions so how do solve this issue in future proof and backwards compatible way?

We can resolve this issue using "webRequest", "webRequestBlocking", API and manually specifying a custom origin header only for the requests sent by the extension but because "webRequest" API is getting removed how can a developer remove "Origin" header without using "webRequest" api?

Using this code we can solve above issue:
```
chrome.webRequest.onBeforeSendHeaders.addListener(
    function (info) {
        if (info.initiator == 'chrome-extension://' + chrome.runtime.id) {
            for (var index = 0; index < info.requestHeaders.length; index++) {
                if (info.requestHeaders[index].name.toLowerCase() === 'origin') {
                    info.requestHeaders[index].value = "https://www.instagram.com/";
                }
            }
            return {requestHeaders: info.requestHeaders};
        }
    },
    {urls: ['*://*.instagram.com/*']},
    ['blocking', 'requestHeaders']
);
```

Origin header absent on get request causing them to succeed:

origin_header_absent.png




Origin header present on post requests, causing them to fail.

origin_header_present.png




Failing request log:

Screenshot_2019-04-28_20-28-13.png






but, when `webRequest` API is deprecated, can `declarativeNetRequest` achieve something similar?
Reply all
Reply to author
Forward
0 new messages