[whatwg/fetch] Cross-Origin Read Blocking (CORB) (#681)

Historically, browsers had rather lax Content-Type checking.  We’ve been able to introduce stricter checks in some cases (e.g. blocking mislabeled scripts and stylesheets in presence of the nosniff header [1]) and unfortunately failed in some other cases (e.g. Firefox’s attempt to block mislabeled images in presence of the nosniff header [2, 3]).

Given Spectre, lax handling of mislabeled cross-origin responses carries new, significant security risks. We've developed a proposal, which we're calling Cross-Origin Read Blocking (CORB), which increases the strictness of cross-origin fetching semantics while trying to still stay web-compatible.  CORB reduces the risk of leaking sensitive data by keeping it further from cross-origin web pages. In most browsers, it keeps such data out of untrusted script execution contexts. In browsers with [Site Isolation](https://www.chromium.org/Home/chromium-security/site-isolation), it can keep such data out of untrusted renderer processes entirely, helping even against speculative side channel attacks.

We're looking to collaborate with everyone on an interoperable set of changes to the web platform, so that blocking of cross-origin responses can be done consistently across all the browsers.  Please take a look at the proposal and its compatibility impact in the [CORB explainer](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md) and provide feedback in this thread on the algorithm itself, as well as on the next steps for trying to encode CORB into the relevant specs for web standards.

We believe that CORB has a reasonably low risk of breaking existing websites (see the “[CORB and web compatibility](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#CORB-and-web-compatibility)” section in the explainer).  We’ve spent a considerable amount of time trying to tweak CORB to minimize compatibility risk (e.g. introducing confirmation sniffing and skipping sniffing for HTML comments since JS can have them too) and are continuing to consider additional tweaks to minimize the risk further (e.g. we are trying to gather data that might inform how to handle text/plain and range requests).  The remaining risk is mostly for nosniff responses labeled with a wrong MIME type - as pointed out above, stricter handling of such responses has always been desirable, but the Spectre threat makes this more urgent.

[1] [https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?](https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?)
[2] [https://github.com/whatwg/fetch/issues/395](https://github.com/whatwg/fetch/issues/395)
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1302539

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/681