Hacker News new | ask | show | jobs
by JimDabell 37 days ago
I think perhaps it’s generational.

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.

3 comments

Gonna play devil's advocate here

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.

That’s not correct at all. Are you confusing it with SameSite or something like that?
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.