Chrome 85 changes to CORS behavior in Chrome Extension Content Scripts

[Łukasz Anforowicz]

Hello,

This is a reminder that the CORS for content script changes will start rolling out with Chrome 85 to the Beta channel on 2020-07-23 as announced earlier.  Please see https://www.chromium.org/Home/chromium-security/extension-content-script-fetches for instructions on how to test if your extension is affected, and for guidelines on how to modify your extension if needed.

To streamline testing, Chrome 85 includes additional options on chrome://flags that can be used to opt into or out of the new behavior.  This should help with testing on systems where command line flags cannot be easily specified (e.g. ChromeOS) and with avoiding mistakes spelling the command line flags.

To opt into the changes (e.g. to test if your extension is affected), set chrome://flags/#cors-for-content-scripts to “Enabled” and chrome://flags/#force-empty-CORB-and-CORS-allowlist to “Enabled”:

    

When testing an extension, look for the following error messages:

Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> with MIME type <type>. See https://www.chromestatus.com/feature/5629709824032768 for more details.

or:

Access to fetch at 'https://another-site.com/' from origin 'https://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

To opt out of the changes (e.g. to verify whether a bug goes away in the absence of CORS-for-content-scripts), set chrome://flags/#cors-for-content-scripts to “Disabled”.

Best regards,

Lukasz Anforowicz and the Chrome Security Architecture team

[Łukasz Anforowicz]

Hello,

This is a reminder that the CORS for content script changes will start rolling out with Chrome 85 to the Stable channel on 2020-08-25 as announced earlier.  Please see https://www.chromium.org/Home/chromium-security/extension-content-script-fetches for instructions on how to test if your extension is affected, and for guidelines on how to modify your extension if needed.

To further reduce disruption amid the ongoing COVID-19 pandemic, we decided to proactively add to the allowlist all the potentially affected extensions that have been detected by Chrome telemetry in earlier Chrome versions.  (This excludes extensions where authors have contacted us to indicate that they have migrated to the new security model. We thank those authors for their efforts and help in keeping Chrome users secure.)  We still plan to deprecate the CORB/CORS allowlist in Chrome 87 and therefore extensions should migrate the new security model as soon as possible.

It is possible that some affected extensions have been missed by the Chrome telemetry pipeline.  For example, to protect user privacy, only public Chrome Web Store extensions have been reported and the reports were discarded if they came from less than 50 unique clients.  If you observe that an extension is broken in Chrome 85 because of CORS or CORB, then please reach out to us by opening a bug - we might be able to help by temporarily adding the extension to the allowlist until Chrome 87.  As a reminder, the error messages to watch out for are:

• Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> with MIME type <type>. See https://www.chromestatus.com/feature/5629709824032768 for more details.

or:

• Access to fetch at 'https://another-site.com/' from origin 'https://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Best regards,

Lukasz Anforowicz and the Chrome Security Architecture team

[Jackie Han]

Just thought of a thing, why those break changes or official announcements only post on this forum mixed with lots of other discussions?

Two suggestions:

• setting up a dedicated announcement mailing list.
• Or email to all extension developers who has a paid CWS account, like the email "[Action Required] Revised Chrome Apps shut down plan"

On Wed, Aug 19, 2020 at 2:27 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

Hello,

This is a reminder that the CORS for content script changes will start rolling out with Chrome 85 to the Stable channel on 2020-08-25 as announced earlier.  Please see https://www.chromium.org/Home/chromium-security/extension-content-script-fetches for instructions on how to test if your extension is affected, and for guidelines on how to modify your extension if needed.

To further reduce disruption amid the ongoing COVID-19 pandemic, we decided to proactively add to the allowlist all the potentially affected extensions that have been detected by Chrome telemetry in earlier Chrome versions.  (This excludes extensions where authors have contacted us to indicate that they have migrated to the new security model. We thank those authors for their efforts and help in keeping Chrome users secure.)  We still plan to deprecate the CORB/CORS allowlist in Chrome 87 and therefore extensions should migrate the new security model as soon as possible.

It is possible that some affected extensions have been missed by the Chrome telemetry pipeline.  For example, to protect user privacy, only public Chrome Web Store extensions have been reported and the reports were discarded if they came from less than 50 unique clients.  If you observe that an extension is broken in Chrome 85 because of CORS or CORB, then please reach out to us by opening a bug - we might be able to help by temporarily adding the extension to the allowlist until Chrome 87.  As a reminder, the error messages to watch out for are:

• Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> with MIME type <type>. See https://www.chromestatus.com/feature/5629709824032768 for more details.

or:

• Access to fetch at 'https://another-site.com/' from origin 'https://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Best regards,

Lukasz Anforowicz and the Chrome Security Architecture team

On Monday, July 20, 2020 at 12:02:42 PM UTC-7 Łukasz Anforowicz wrote:

Hello,

This is a reminder that the CORS for content script changes will start rolling out with Chrome 85 to the Beta channel on 2020-07-23 as announced earlier.  Please see https://www.chromium.org/Home/chromium-security/extension-content-script-fetches for instructions on how to test if your extension is affected, and for guidelines on how to modify your extension if needed.

To streamline testing, Chrome 85 includes additional options on chrome://flags that can be used to opt into or out of the new behavior.  This should help with testing on systems where command line flags cannot be easily specified (e.g. ChromeOS) and with avoiding mistakes spelling the command line flags.

To opt into the changes (e.g. to test if your extension is affected), set chrome://flags/#cors-for-content-scripts to “Enabled” and chrome://flags/#force-empty-CORB-and-CORS-allowlist to “Enabled”:

    

When testing an extension, look for the following error messages:

Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> with MIME type <type>. See https://www.chromestatus.com/feature/5629709824032768 for more details.

or:

Access to fetch at 'https://another-site.com/' from origin 'https://example.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

To opt out of the changes (e.g. to verify whether a bug goes away in the absence of CORS-for-content-scripts), set chrome://flags/#cors-for-content-scripts to “Disabled”.

Best regards,

Lukasz Anforowicz and the Chrome Security Architecture team

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/32a7da0f-dabd-4ecc-8cb0-7887f94375dcn%40chromium.org.

--

韩国恺(Jackie)

[Łukasz Anforowicz]

On Thu, Aug 20, 2020 at 12:11 PM Jackie Han <han.g...@gmail.com> wrote:

Just thought of a thing, why those break changes or official announcements only post on this forum mixed with lots of other discussions?

Two suggestions:

• setting up a dedicated announcement mailing list.
• Or email to all extension developers who has a paid CWS account, like the email "[Action Required] Revised Chrome Apps shut down plan"

Thank you for the feedback.  I'll let Devlin and Simeon answer the suggestion for a separate mailing list for announcements.  It seems like a reasonable idea to me.

Let me clarify though that the CORS-for-content-scripts have also been announced via:

• Chrome Enterprise Release Notes (since Chrome 81).
• We *did* send individual emails to authors of the potentially affected extensions (ones caught by telemetry in earlier Chrome versions).  Email addresses were indeed taken from the CWS database.

Thanks,

Lukasz

[guest271314]

Does this affect the ability to make cross-origin requests in background scripts? Currently it does not appear to be possible to fetch() localhost from a background script, even when --disable-web-security is set and localhost is listed in treat insecure origins as secure. Am working on a project with two paths (https://bugs.chromium.org/p/chromium/issues/detail?id=1115640) where the capability to fetch() from localhost is the current restriction to further testing. Kindly illuminate what the official procedure is to make a cross-origin request to localhost using fetch() (https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Crl6VuMKPic/m/KisJUs8MBwAJ) without a network error being thrown.

[Inter Net]

chrome://flags/#force-empty-CORB-and-CORS-allowlist  Does not exist in my flags 

[Łukasz Anforowicz]

On Sun, Aug 23, 2020 at 6:23 AM guest271314 <guest...@gmail.com> wrote:

Does this affect the ability to make cross-origin requests in background scripts?

CORS-for-content-script changes (that will soon begin rolling out with Chrome 85 to the Stable channel) should *not* affect the behavior of extension background pages.  Only the behavior of content scripts should be affected.  

 

Currently it does not appear to be possible to fetch() localhost from a background script, even when --disable-web-security is set and localhost is listed in treat insecure origins as secure. Am working on a project with two paths (https://bugs.chromium.org/p/chromium/issues/detail?id=1115640) where the capability to fetch() from localhost is the current restriction to further testing.

I see that https://crbug.com/1115640 is related to Native Messaging (rather than to XHR/fetch).  For example, I don't see the string "localhost" or "127.0.0.1" mentioned in the bug.

 

Kindly illuminate what the official procedure is to make a cross-origin request to localhost using fetch() (https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Crl6VuMKPic/m/KisJUs8MBwAJ) without a network error being thrown.

I think that if the extension manifest asks for permission to localhost, then CORS/CORB-bypassing-fetch/XHR to localhost should work from extension background pages:

{
  "name": "My extension",
  ...
  "permissions": [
    "http://localhost/*"
  ],
  ...
}

If localhost XHRs/fetches from an extension background page don't work (despite the permission above), then it seems to be a Chrome bug (separate I think from CORS-for-content-scripts and from https://crbug.com/1115640).  Could you please report the bug through https://crbug.com/new and the CORS and/or extensions teams will be able to help further.  (Feel free to reply with a bug number here as well.) 

I am sorry I wasn't able to help further.  Best regards,

Lukasz

[Łukasz Anforowicz]

+Takashi Toyoshima in case this is related to CORS and you're able to help

On Mon, Aug 24, 2020 at 8:34 AM Łukasz Anforowicz <luk...@chromium.org> wrote:

On Sun, Aug 23, 2020 at 6:23 AM guest271314 <guest...@gmail.com> wrote:

Does this affect the ability to make cross-origin requests in background scripts?

CORS-for-content-script changes (that will soon begin rolling out with Chrome 85 to the Stable channel) should *not* affect the behavior of extension background pages.  Only the behavior of content scripts should be affected.  

 

Currently it does not appear to be possible to fetch() localhost from a background script, even when --disable-web-security is set and localhost is listed in treat insecure origins as secure. Am working on a project with two paths (https://bugs.chromium.org/p/chromium/issues/detail?id=1115640) where the capability to fetch() from localhost is the current restriction to further testing.

I see that https://crbug.com/1115640 is related to Native Messaging (rather than to XHR/fetch).  For example, I don't see the string "localhost" or "127.0.0.1" mentioned in the bug.

 

Kindly illuminate what the official procedure is to make a cross-origin request to localhost using fetch() (https://groups.google.com/a/chromium.org/g/chromium-extensions/c/Crl6VuMKPic/m/KisJUs8MBwAJ) without a network error being thrown.

I think that if the extension manifest asks for permission to localhost, then CORS/CORB-bypassing-fetch/XHR to localhost should work from extension background pages:

{
  "name": "My extension",
  ...
  "permissions": [
    "http://localhost/*"
  ],
  ...
}

If localhost XHRs/fetches from an extension background page don't work (despite the permission above), then it seems to be a Chrome bug (separate I think from CORS-for-content-scripts and from https://crbug.com/1115640).  Could you please report the bug through https://crbug.com/new and the CORS and/or extensions teams will be able to help further.  (Feel free to reply with a bug number here as well.) 

Or maybe you meant https://crbug.com/1096150?   

[Hr Gwea]

On Monday, August 24, 2020 at 11:35:38 AM UTC-4, Łukasz Anforowicz wrote:

CORS-for-content-script changes (that will soon begin rolling out with Chrome 85 to the Stable channel) should *not* affect the behavior of extension background pages.  Only the behavior of content scripts should be affected.  

 

Is it correct to assume that no extension page will be affected by this change?

That is, any page whose URL starts with chrome-extension://

[Charlie Reis]

chrome://flags/#force-empty-CORB-and-CORS-allowlist was introduced in Chrome 85.  As noted on https://www.chromium.org/Home/chromium-security/extension-content-script-fetches/, you can use command line flags to force the feature to be enabled or disabled as well (back to Chrome 81).

Enable:

--force-empty-corb-allowlist
--enable-features=OutOfBlinkCors,CorbAllowlistAlsoAppliesToOorCors

Disable:

--disable-features=CorbAllowlistAlsoAppliesToOorCors
--enable-features=OutOfBlinkCors

Hope that helps,

Charlie

[Charlie Reis]

Correct, chrome-extension:// pages should be unaffected.

Charlie