Chrome 83 changes to CORS behavior in Chrome Extension Content Scripts

1,585 views
Skip to first unread message

Łukasz Anforowicz

unread,
Mar 9, 2020, 12:36:49 PM3/9/20
to Chromium Extensions, Charlie Reis, Devlin Cronin, sim...@chromium.org

Hello extension authors!


As part of an effort to improve Chrome Extension security, cross-origin fetches are being disallowed from content scripts in Chrome Extensions.  Cross-Origin Read Blocking (CORB) has already applied to content scripts since M73.  We plan to also enable CORS for content script requests starting in M83, which will reach the stable channel around June 9th.  We expect most extensions to be unaffected by the CORS change, but there is a chance that some requests initiated from content scripts may start to fail.


Please test your Chrome Extension to make sure it works with the new behavior when Chrome is launched with the following cmdline flags (in 81.0.4035.0 or later):

--enable-features=OutOfBlinkCors,CorbAllowlistAlsoAppliesToOorCors

During the test watch for fetches or XHRs that are initiated by content scripts and blocked by CORS with a DevTools console message similar to:

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.

The changes should only affect fetches or XHRs for content types not blocked by CORB (such as images, JavaScript, and CSS), and only if the server does not approve the CORS request with an Access-Control-Allow-Origin response header.  If your extension is affected, then please open a bug to add the affected extension to a temporary allowlist.


We plan to enable the CORS changes by default in M83 for Canary and Dev users around March 16th.  We plan to ship the changes to the Beta and Stable channel in M83, although we may make adjustments to this plan based on feedback and telemetry results.  According to the Chromium Dashboard, the M83 Beta release is tentatively scheduled for May 7th and the M83 Stable release for June 9th.


If your extension is already present on the CORB allowlist, then its behavior will not be affected by the M83 changes (because the same allowlist exempts an extension from both the M73 CORB changes and from the M83 CORS changes).  At this point we don’t have a specific timeline for removing extensions from the allowlist. However, since users of allowlisted extensions are at a higher security risk, we encourage extensions to move to the new security model and migrate off of the allowlist as soon as possible.  We hope to announce a more specific allowlist timeline after the M83 changes ship to the stable channel.


Fortunately, if your extension is currently present on the CORB allowlist, then the M83 CORS changes may actually help you remove the extension from the allowlist.  This is because the server may now send a valid `Access-Control-Allow-Origin` response header based on the page's origin, in which case CORB will not block the response.  To see if your extension might be eligible for removal from the allowlist after the M83 changes, test your extension after launching Chrome with the following command-line flags (in 81.0.4035.0 or later):

--enable-features=OutOfBlinkCors,CorbAllowlistAlsoAppliesToOorCors

--force-empty-corb-allowlist


For more details please see: https://www.chromium.org/Home/chromium-security/extension-content-script-fetches 


Thank you in advance for your help in keeping Chrome's users secure!


Lukasz Anforowicz and the Chrome Security Architecture team

Scott Fortmann-Roe

unread,
Mar 11, 2020, 7:07:33 AM3/11/20
to Łukasz Anforowicz, Chromium Extensions, Charlie Reis, Devlin Cronin, Simeon Vincent
Thank you for this heads up.

For testing, is it possible to enable those feature flags from chrome://flags or do they need to be enabled from the command line? Specifically, I remember the out-of-blink-cors flag being available two months ago when I was testing, but I don't see it when I checked today. I was wondering if it has been changed or if it is an issue with my setup.

--
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/CAA_NCUHAEB%2BWgzRLiOvMdDEHOUpi%3Dafr11eJXcG-wNHDZBUF_Q%40mail.gmail.com.

Łukasz Anforowicz

unread,
Mar 11, 2020, 12:12:17 PM3/11/20
to Scott Fortmann-Roe, Chromium Extensions, Charlie Reis, Devlin Cronin, Simeon Vincent
On Wed, Mar 11, 2020 at 4:07 AM Scott Fortmann-Roe <sco...@gmail.com> wrote:
Thank you for this heads up.

For testing, is it possible to enable those feature flags from chrome://flags or do they need to be enabled from the command line?

Great idea - thanks!  I'll try adding chrome://flags/#cors-for-content-scripts to M82, in the CL here: https://chromium-review.googlesource.com/c/chromium/src/+/2098258.  The flag should help if we need to ask end-users for help with diagnosing extension behavior issues that might be related to the new M83 behavior.

I assume that most end users don't really need to test with --force-empty-corb-allowlist and that extension authors can use command line flags.
 
Specifically, I remember the out-of-blink-cors flag being available two months ago when I was testing, but I don't see it when I checked today. I was wondering if it has been changed or if it is an issue with my setup.

I believe that chrome://flags/#out-of-blink-cors flag was removed during M82 (see https://chromium-review.googlesource.com/c/chromium/src/+/2065255), because the feature is now enabled almost everywhere (*).  In particular OOR-CORS has been made the default in M81 (see https://chromium-review.googlesource.com/c/chromium/src/+/1988127) although field trials might still be used in M81 and earlier to introduce a 1% holdback group for A/B analysis.

(*) "almost everywhere" = the only remaining exemptions that I am aware of are: 1) an enterprise policy (which will be removed soon) and 2) 1% holdback group in field trials in M81 and earlier.  OTOH, I am not on the OOR-CORS team, so take my statements here with a grain of salt please :-).

Deco

unread,
Mar 11, 2020, 12:42:29 PM3/11/20
to Łukasz Anforowicz, Chromium Extensions, Charlie Reis, Devlin Cronin, Simeon Vincent
Thanks for the notice, reading the updated guidance for CORS, it seems that the allowlist will be eventually retired on release of manifest V3, however will this place during the migrationary period, or after updates have reached the stable build (or is this not known)?

Regards,

--

Łukasz Anforowicz

unread,
Mar 11, 2020, 3:35:07 PM3/11/20
to Deco, Chromium Extensions, Charlie Reis, Devlin Cronin, Simeon Vincent
On Wed, Mar 11, 2020 at 9:42 AM Deco <decklin...@gmail.com> wrote:
Thanks for the notice, reading the updated guidance for CORS, it seems that the allowlist will be eventually retired on release of manifest V3, however will this place during the migrationary period, or after updates have reached the stable build (or is this not known)?

Allowlist does not apply to manifest V3 extensions.  In other words, manifest V3 extensions cannot opt out of having CORB (and after M83 CORS) applied to their content scripts.  From that perspective, extensions will need to migrate to the new security model before manifest V2 extensions are deprecated.  AFAIK there is no timeline yet for manifest V2 extensions deprecation.

To improve security of Chrome users we may try to deprecate the allowlist before deprecating manifest V2 extensions.  At this point there are no detailed plans or timelines for the allowlist deprecation.  We hope that we'll be ready to discuss allowlist deprecation once the M83 changes successfully ship to the stable channel - most likely this translates into having a discussion about allowlist deprecation some time in Q3 2020 and actually deprecating the allowlist some time in Q4 2020.

While there are no looming deadlines, I want to note that users of allowlisted extensions are at a higher security risk.  In particular, such users may become a victim of an attack where a compromised renderers steals cross-origin secrets (e.g. bypasses CORB to steal an email or a bank statement) or initiates cross-origin actions (bypassing CORS).  Because of this, we strongly encourage extension authors to migrate to the new security model as soon as possible (removing their extension from the allowlist).


-Lukasz

Łukasz Anforowicz

unread,
Mar 23, 2020, 3:12:51 PM3/23/20
to Chromium Extensions, cr...@chromium.org, rdevlin...@chromium.org, sim...@chromium.org
We decided to postpone enabling CORS for content script requests - this change won't go into effect until M84.  This decision will help us align with the Chrome schedule changes that were announced last week (here and here).

At this point we plan to enable CORS for content scripts early during the M84 milestone (i.e. a few days after the M83 branch point).  Note that the release schedule for M84 have not been finalized at this point.  We will post updates when new information is available.

Note that CORS for content scripts was enabled for a few Canary versions last week, but the old behavior should be restored in version 83.0.4092.0 and later.

Thanks,

Lukasz

Vasco Gomes

unread,
Mar 24, 2020, 1:15:36 PM3/24/20
to Chromium Extensions, cr...@chromium.org, rdevlin...@chromium.org, sim...@chromium.org
Thank you for the update :)

I think that Manifest V3 should also be paused/canceled.
There is a huge disappointment from extension developers about it. Specially the removal of background scripts and removal of webrequest. 
I'm sure that a huge number of extensions (+50%) will see their features broken or crippled by Manifest V3. Don't send Extensions back 10 years in time.

I just hope that with this pause the Chrome team can listen to Extension Devs once and for all and rethink the Manifest V3. 
I have never seen such crisp environment when talking about Manifest V3. I think that Chrome should go the Android route adding more features (not cutting features) and the creation of Lite extensions that should follow a new set of rules.
Devs could release their extensions in the standard version and Lite version and users could choose between the two. Just like Google, Facebook and so on does on Play Store making available App in normal and Lite form.

Greetings.

Łukasz Anforowicz

unread,
Apr 1, 2020, 7:33:22 PM4/1/20
to Chromium Extensions, cr...@chromium.org, rdevlin...@chromium.org, sim...@chromium.org
We decided to postpone enabling CORS for content script requests a bit further - this change won't go into effect until M85.  This follows the Chrome guidance to avoid deprecations and breaking changes in the near time - this should help avoid disruptions at a time when extension authors might not be able to react to the announced changes + when Chrome users are especially relying on the stability of the Chrome browser.

Thanks,

Lukasz

Łukasz Anforowicz

unread,
May 18, 2020, 12:24:24 PM5/18/20
to Chromium Extensions, cr...@chromium.org, rdevlin...@chromium.org, sim...@chromium.org
Status update: CORS for content scripts has been enabled for 100% of M85, Canary/Dev channel users.  Please see the previous post for instructions on how to check if your extension is affected and how to request allowlisting if needed.

Thanks,

Lukasz
Reply all
Reply to author
Forward
0 new messages