Deprecation and removal of the CORB/CORS allowlist in Chrome 87

[Łukasz Anforowicz]

Hello,

We plan to deprecate and remove the CORB/CORS allowlist in Chrome 87.  The allowlist has been introduced in Chrome 73 to help extensions transition to a new security model, where content scripts are no longer able to bypass CORB and (since Chrome 85) CORS.  According to the Chrome dashboard, the Chrome 87 release is tentatively scheduled to ship to the Beta channel around 2020-10-15 and to the Stable channel around 2020-11-17.

The decision to deprecate the allowlist is primarily motivated by the desire to keep Chrome users secure: restricting capabilities exposed to content scripts helps prevent leaking these abilities to malicious webpages that may be hosted in the same renderer process.  Additionally the planned “CORS for content scripts” changes are on track to ship in Chrome 85 and should allow removing many extensions from the allowlist: those that were only allowlisted because their content script requests needed to be approved by CORS (e.g. because Chrome did not send the `Origin` HTTP request header before Chrome 85).

To see if your extension is affected, test your extension by launching Chrome (version 83.0.4103.50 or later) with the following command line flags:

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

If your extension's content scripts make requests that don’t work when Chrome is launched with the command line flags above, then you need to change your extension to keep it working in Chrome 87 and above.  In particular, you might need to update your extension to initiate cross-origin fetches from the extension background page (instead of from a content script).

It is possible that your extension continues to work fine when Chrome is launched with the command line flags above, even if your extension has been added to the allowlist in the past. This likely indicates that the Chrome 85 changes make it possible to simply remove your extension from the allowlist.  In that case, you don’t need to take any action to keep your extension working in Chrome 87 and above.

To learn more about the Chrome 73, 85 and 87 changes to how content scripts interoperate with CORB and CORS please read the “Changes to Cross-Origin Requests in Chrome Extension Content Scripts” document.  In the document you will find more information about the allowlist, as well as guidance on how to transition your extension to the new security model.

Thank you in advance for your help in keeping Chrome's users secure!
 
Lukasz Anforowicz and the Chrome Security Architecture team

[Łukasz Anforowicz]

Hello,

As previously announced, the CORB/CORS allowlist has been removed in Chrome 87.  These Chrome 87 changes may break Chrome Extensions that were on the allowlist but haven’t yet migrated to the new security model.  The tentative Chrome 87 release schedule is to ship to the Beta channel on 2020-10-15 and to start rolling out to the Stable channel on 2020-11-17 (right now the changes are present in Chrome Canary and Chrome Dev release channels).

If your extension was on the allowlist or was otherwise affected by the CORB-for-content-scripts changes in Chrome 73 or CORS-for-content-scripts changes in Chrome 85, then we recommend that you re-test your extension on the latest Chrome Dev release.  We recommend this even if you have previously tested and verified that the extension works without the CORB/CORS allowlist, to ensure that it still works as expected in the final stage of the migration in Chrome 87.

No special flags or switches need to be used when executing the tests in Chrome 87.0.4266.0 and higher, since the new CORS and CORB behavior is enabled and the allowlist has been removed.   Note that Chrome Dev and Chrome Beta can be installed side-by-side with a Chrome release from the Stable channel - this should allow testing these versions without affecting your usual Chrome Stable profile.  As a reminder, the Chrome changes might affect XHR and `fetch` APIs used within content scripts of Chrome Extensions and might trigger CORS errors:

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

or CORB warnings:

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

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

Thank you for your help in updating extensions to support the new security requirements within the announced schedule. If you encounter any issues related to the deprecation, please open a Chromium bug to reach us.

Best regards,

Łukasz Anforowicz (on behalf of the Chrome Security Architecture team)

[Hr Gwea]

I have a question, please.

If the webpage http://domain-A.com/page.html contains this HTML:

<img src="http://domain-B.com/image.jpg">

And let's assume the image is shown successfully.

Under what conditions is a content script in that page allowed to perform an HTTP request for that image?

Does the Access-Control-Allow-Origin field on the image response need to be set to domain-A.com?

What if the image has no Access-Control-Allow-Origin?

[PhistucK]

I believe only fetch/XMLHttpRequest calls are affected by this. Images, scripts, embeds, objects and so on can be embedded from wherever in normal web pages. Content scripts do not have more restrictions than normal web pages, from what I know.

This change basically makes content scripts match those normal-web-page restrictions.

☆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 view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/556c4962-a3a9-42c9-9a7c-c0002e621edeo%40chromium.org.

[Łukasz Anforowicz]

On Mon, Sep 28, 2020 at 12:28 AM PhistucK <phis...@gmail.com> wrote:

I believe only fetch/XMLHttpRequest calls are affected by this. Images, scripts, embeds, objects and so on can be embedded from wherever in normal web pages. Content scripts do not have more restrictions than normal web pages, from what I know.

This change basically makes content scripts match those normal-web-page restrictions.

Yes - exactly!

 

☆PhistucK

On Mon, Sep 28, 2020 at 2:20 AM Hr Gwea <hrg...@gmail.com> wrote:

I have a question, please.

If the webpage http://domain-A.com/page.html contains this HTML:

<img src="http://domain-B.com/image.jpg">

And let's assume the image is shown successfully.

Under what conditions is a content script in that page allowed to perform an HTTP request for that image?

Does the Access-Control-Allow-Origin field on the image response need to be set to domain-A.com?

What if the image has no Access-Control-Allow-Origin?

As PhistucK pointed out, after M85 the same restrictions apply to content scripts as the restrictions that apply to a webpage:

• When making a cross-origin XHR or `fetch`, CORS will apply by default.  CORS means that the request will fail unless the server replies with `Access-Control-Allow-Origin: ......` response header that matches the origin of the request initiator.
• For `fetch` (I am not sure about XHR) one can explicitly set the request mode to "no-cors".  In such mode CORS is turned off, but the response is opaque to javascript (i.e. javascript cannot see/read bytes of the response body or see/read response headers).
• <img src> and Image(...) both issue "no-cors" requests under the covers, but they can decode the pixels (i.e. a "no-cors" response is opaque to javascript, but not to image decoders).  Note that sometimes image pixels may get exposed to Javascript (e.g. via canvas), so there are some extra rules that govern how cross-origin images may be used with canvas and similar scenarios: https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_enabled_image   

I hope this helps?  :-)

If your extension is affected by the recent/M85 CORS-for-content-scripts changes or the earlier/M73 CORB-for-content-scripts changes, then supporting the new security model should be possible by moving some of your XHRs/fetches from content scripts to the extension background page (being careful to avoid letting content scripts ask for *any* URL and introducing an open-proxy / confused-deputy problem - see the "Limit Cross-Origin Requests in Background Pages" section in https://www.chromium.org/Home/chromium-security/extension-content-script-fetches). 

--
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/556c4962-a3a9-42c9-9a7c-c0002e621edeo%40chromium.org.

--

You received this message because you are subscribed to a topic in the Google Groups "Chromium Extensions" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-extensions/IvSsLxXajyA/unsubscribe.
To unsubscribe from this group and all its topics, 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/CABc02_Ju0aKDyRHXdBGQV4fFESgiMbJ_pv%2BV8u_w1YMUUY57Vw%40mail.gmail.com.

[Hr Gwea]

On Monday, September 28, 2020 at 1:15:49 PM UTC-3, Łukasz Anforowicz wrote:

I hope this helps?  :-)

Got it. Content scripts have the same restrictions on HTTP requests as the page scripts.

Thanks!

[Łukasz Anforowicz]

I wanted to send a quick reminder about the CORB/CORS allowlist deprecation in Chrome 87:

• The allowlist deprecation has been shipping to Chrome Beta channel since October 15th (around 2.5 weeks ago).
• The allowlist deprecation will reach Chrome Stable on November 17th (around 2.5 weeks from now).

Best regards,

Lukasz