Lucas, are you best placed to take a look at this?

That URL doesn't look like it has a nosniff response header.  As a result, Chrome has to sniff the content to confirm if it's actually application/json or not, because a lot of JavaScript content on the web is mislabled and Chrome would break existing sites if it blocked such content.

More info here:
https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

If existing content can get updated to be labeled correctly, we can remove the confirmation sniffing requirement for responses that don't have nosniff headers.

Let me know if I misunderstood the scenario, but otherwise I think this is by design (to preserve compatibility) and thus a WontFix.

Thank you for the report and for looking at Cross-Origin Read Blocking.

I assume that this report is about the request to http://bughuntersclub.ipage.com/rm/xss?xss=%7bfoo:%20alert(1)%7d&type=application/json.  I have the following observations about this request:
- Response headers include "Content-Type: application/json".  This makes the response eligible for CORB protection.
- Response headers do not include "X-Content-Type-Options: nosniff".  This means that CORB needs to sniff the response body, to confirm if it really is JSON.
- Response body looks as follows:
    {foo: alert(1)}
  CORB sniffer will not classify this as valid JSON.  Therefore CORB will not protect this response.
  AFAICT the response body is indeed not a valid JSON document - the response body does not conform to the grammar from https://www.json.org.

More notes:
- Currently CORB sniffing is not standardized anywhere, but the current implementation can be seen in CrossOriginReadBlocking::SniffForJSON (also note sniffing for JSON security prefix in CrossOriginReadBlocking::SniffForFetchOnlyResource).
- CORB sniffing is a best-effort heuristics (e.g. consider that CORB will *not* (!) sniff some html/javascript polyglots as html which means that backcompatibility is preserved, but CORB-protection suffers;  see  issue 839945  and  issue 839425 ).  To ensure protection of sensitive resources we recommend using "X-Content-Type-Options: nosniff".

Based on the above, I think everything is working as intended.  Unless I am missing something, I think this bug can be resolved as WontFix/WAI.

I don't think that makes sense because
- The response has correct 'Content-type' of 'application/json' which doesn't require sniffing
- Adding nosniff header already does the blocking and shouldn't require CORB be enabled (idk if that's what explainer explicitly asks for)
- The response content is indeed a valid JSON, so sniffing should yield the same result
- Not only JSON but any previously executing MIME types are executecd even with SiteIsolation enabled (text/html, text/xml, etc.)
- The same doesn't apply to <link> which is probably because of CORB 
For example, visiting below link doesn't apply referenced stylesheet because the returned content-type is text/html;
http://cm2.pw/xss?xss=%3Clink%20rel=stylesheet%20href=%27//bughuntersclub.ipage.com/rm/xss?xss=*%25257bbackground:%20red%25257d%2526type=text/html%27%3E

Ohh, #4 was in response to #2. 

> - Response headers do not include "X-Content-Type-Options: nosniff".  This means that CORB needs to sniff the response body, to confirm if it really is JSON.
Does it require sniffing even when explicitly specified to be json via 'content-type' header?

Thanks for your clear explanation and I'm fine if it's WAI.

RE: Does it require sniffing even when explicitly specified to be json via 'content-type' header?

This is unfortunate, but yes - CORB needs to sniff to avoid blocking responses that are mislabeled (i.e. served with a Content-Type that doesn't match the response body).

I don't have specific data readily available, but anecdotally - there are lots and lots of images out there which are served as text/html.  Ideally CORB would block such responses, but this would break existing websites.  So - CORB won't block such responses unless 1) nosniff response header is present or 2) the response matches Content-Type according to CORB confirmation sniffing.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot