*Creates a rest api that runs on localhost:8080*
*Creates React front end that runs on localhost:3000*
*Sends a GET request to api*
*Cross-Origin Request Blocked: The Same Origin Policy...*

Thats my fucking dev environment and its my local fucking host! Let me just send a fucking request to my own fucking machine you piece of shit! Why the fuck they didn't add an exclusion to fucking localhost?!?

@hack Because there are legitimate reasons for that.
Every exclusions by default makes the solution more error prone. There are also normal applications listening on localhost.

CORS is just a fucken brainfart imho.

@nitwhiz It's really important.
Why don't you think so?

@PrivateGER because it's implemented so poorly. The download happens and basically tells you 200 OK but the browser rejects using the ressource (wtf). Nextup, it's a breaking change brought into the ecosystem. It's like python changing it's backwards compatibility.
And why should a ressource decide where it's going to be downloaded to? Wouldn't it make more sense to decide where ressources are allowed to be downloaded from? Both are equally manipulateable in the end of the day but the latter is way more intuitive.

I can get that these reasons are subjective and maybe not even important for you but as you tell me CORS is important - Tell me why. And especially tell me why it needs to be applied to requests originating from *://localhost:*?

@nitwhiz I think a resource should definitely be able to decide where it can be downloaded to. It just makes sense to me.

CORS being applied to localhost is because many applications listen on localhost. It'd be dangerous to allow full access to everything there.

@nitwhiz The "the Browser does not use the resource" has the reason so you can't steal csrf tokens embedded in forms of other websites.
The request still goes through, depending on the content type (e.g. a JSON POST will do a "pre-flight" HEAD so no data is transfered if not allowed) because otherwise (automated) form transmission across origins would break.

Additionally this teaches application developers to correctly apply CORS headers (or avoid CORS completely) at the beginning of the development.

@PrivateGER @sbiewald from your point of view it makes sense, of course but it means i got another dev/live system branch to decide if localhost should be in there or not.

From a web dev point of view it's annoying to say the least..

Btw PrivateGER, finally found someone disliking Python, too, props to you.:D

Header cross my bat origin : *

@nitwhiz Because you asked the question, why a resource should decide where it is downloaded from:
A browser is able to send cookies / credential for CORS requests. Just imagine if any website could just read CSRF tokens from or call /api/getUsersApikey from third party websites.

And as said before: There are a lot of applications running on localhost, some maybe even as administrator (a year ago an Antivirus, and it accidentally had Access-...: * set, so any website could disable it).

And by the way, you can restrict which site can you reached from your site, too: With the Content-Security-Policy header. You can restrict to which sites you can do an XHR or include JavaScript from, if images should only be loaded from HTTPS or disallow inline CSS.

And one last thing: Chrome has the flags --disable-web-security --user-data-dir=/tmp/dev which completely disables the same origin policy (USE IT IN AT YOUR OWN RISK).

@sbiewald but you know CORS is a pretty new thing?
Especially APIs are meant to be called from everywhere. It's your beer to verify the Bearer-Token you should expect in the requests Header.

Imho that's just fighting the symptom. The real problem - insecure endpoints - still persists.

@nitwhiz No, not all APIs are to be called from everywhere.
I'm rather sure the GMail-JSON-Api of the webmail client is just for the webmail client.

And adding *one* header if you want to access your API from everywhere is not to difficult to justify to drop the same origin policy (which is much older).

Also CORS is standardized since 5 years (but I guess it works a bit longer (the respective JavaScript APIs are available in Chrome 3, from 2009).