Why don't Internet browsers allow me to fetch a JSON file from raw.githubusercontent.com, but they allow me to fetch .psm files from there?

Question

When I was making my PicoBlaze Simulator in JavaScript, I added 6 examples of how to use it. Those examples are on my GitHub profile, they are the .psm (PicoBlaze Assembly) files. I decided not to hard-code the links to those .psm files in my JavaScript, but to write a JSON file containing the links to them. However, I remember that browsers would not allow me to fetch that examples.json file from raw.githubusercontent.com, that I had to copy examples.json from my GitHub profile to my website in order to be able to fetch it. Nevertheless, browsers do allow me to fetch the .psm files from my GitHub profile. Why is it so?

What is the threat model because of which browsers do not allow one to fetch.json files from raw.githubusercontent.com? I understand that it is not a good idea to take JavaScript .js files directly from somebody's GitHub profile: files on somebody's GitHub profile are not supposed to be well-tested (That's why you are not supposed to download the source code of some program from GitHub to build it, as many websites warn you, "There can quite possibly be bugs, in fact, the code might not even compile."). Furthermore, one who owns that file (and browsers cannot know it is me) could easily do a cross-site scripting attack on every website that uses that JavaScript if that were allowed. But .json files are not executable JavaScript, they cannot contain cross-site scripting attacks. So, why aren't browsers allowing us to fetch.json files from raw.githubusercontent.com?

In my Bachelor Thesis, I speculate that that decision dates back to the time when JSON was parsed using eval (rather than JSON.parse), so that somebody could indeed make a cross-site scripting attack by modifying the .json file to contain invalid JSON (which JSON.parse would reject, but eval would accept). Is that correct?

Answer 1

The feature you describe is either Cross-Origin Read Blocking (CORB) or Opaque Response Blocking (ORB). It blocks specific media types like application/json, text/plain and text/html, while other types are accepted. You can reproduce the error in older browsers (I've tested Chromium 73, not sure about Firefox). The code is as follows:

<script> jsonUrl = "https://raw.githubusercontent.com/FlatAssembler/PicoBlaze_Simulator_in_JS/master/examples.json"; fetch(jsonUrl, {mode: "no-cors"}); </script> 

This will produce the following error message:

Cross-Origin Read Blocking (CORB) blocked cross-origin response https://raw.githubusercontent.com/FlatAssembler/PicoBlaze_Simulator_in_JS/master/examples.json with MIME type text/plain. See https://www.chromestatus.com/feature/5629709824032768 for more details. 

A possible explanation for why you might have ended up with no-cors mode is that raw.githubusercontent.com didn't always allow CORS. In that case, the browser will recommend using no-cors, which in turns leads to the above error.

Currently, raw.githubusercontent.com does allow CORS, so it should be possible to fetch any resource in cors mode, regardless of the type. In no-cors mode, modern browsers no longer seem to display the above CORB error. However, the error is still displayed when you try to load the JSON file with a script element.

As to the idea behind this feature: CORB has nothing to do with preventing cross-site scripting. Instead, it is supposed to prevent cross-origin access to sensitive data through side-channel attacks like Spectre and Meltdown. The attack scenario is that a file which may contain sensitive user data (like HTML, XML or JSON) is loaded from a malicious website through an img or script element or fetch in no-cors mode. This is possible despite the same-origin policy and without CORS headers. Scripts from the malicious site cannot directly access the response, but the file content will be loaded into browser memory in order to render, execute or cache it. Through Spectre or Meltdown, it may then be possible to access the content in memory through Spectre/Meltdown exploits written in JavaScript.