If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along and CORS was created to bypass this security. Therefore to do the thing you want to do, you need to enable CORS. No problem, that’s pretty easy.
If you only picked up web development after CORS existed, then you try to make a cross-origin request; the browser understands that it isn’t allowed; the browser tries to do a CORS preflight request; the preflight request fails; and the browser reports a CORS error in the console.
So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it.
It doesn’t help matters that a whole bunch of people with the same misunderstanding will confidently repeat that misunderstanding in tutorials and online discussions.
I think to some extent CORS and SOP are a bit equivocated somewhat intentionally... i.e. CORS is a used as a shorthand for SOP because CORS is a more well known term, especially in its acronymized form.
Consider for example the error I get when opening up the console on Google's homepage
> Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://play.google.com/log?format=json&hasfast=true. (Reason: CORS request did not succeed). Status code: (null).
There is a reference to the SOP in here but it starts off with "Cross-Origin Request" and also says "CORS request did not succeed". Which makes it sound like CORS is the problem or the thing doing the blocking or that "CORS" is enforcing the "Same Origin Policy". Chrome, I've heard, is even more cryptic
Also, it feels like one of those things that are a little pedantic to mention in a discussion irl, so that's probably why the term CORS sticks and the term SOP doesn't
> If you were a web developer before CORS existed, then you understand that cross-domain requests were forbidden all along
They weren't though. We had to adjust in the 2010s so existing code wouldn't break. It was something like, Chrome set a deadline after which it would be forcing the same-origin security by default, where it was off or optional before.
I may be wrong about the specific security thing involved, but I know it would have broken ajax requests (probably XMLHTTPRequest, not fetch) to different domains had we not made changes to deal with it. They worked without issues before that.
You could not make cross-domain Ajax requests at all until CORS came along. There were lots of workarounds people had to invent (e.g. JSONP, Flash shims, proxying, etc.) precisely because this security barrier has been in place since the mid-90s, a couple of decades before CORS came along.
The whole point of CORS was to enable cross-domain requests.
> So if you don’t understand what’s going on, don’t RTFM, and just guess, you’re going to guess that CORS is the thing that is blocking the request and that you need to disable CORS. And that leads you directly into a confusing mess because you are trying to do the exact opposite of what you need to do. CORS is the solution to your problem, not the cause of it.
Great explanation. The name is quite obvious actually, Cross-Origin Resource Sharing. People should understand if they read it.
100% - although it is stunning to see since most LLMs get CORS questions right (which is surprising since they trained on all sorts of incorrect data).
Maybe it’s like that trick where if a thousand people guess the amount of beans in a jar almost all of them will be wrong but their average will be very close to, if not, correct.
