But there are valid situations where you want a request from 1 domain to be made to other domains. This is where CORS comes in.
CORS is a mechanism to loosen security, not increase it. It allows a server to say, these are the domains (outside my own domain) who can make requests. CORS headers should be set carefully so that you are only allowing the domains that should be allowed through.
Or we could call it CORB instead (Cross origin request blocking), and then we see it's a mechanism to tighten security. Since fundamentally, what we have is an agreement against major web browser vendors that blocks cross origin requests unless the web server authors have used CORS.
I mean, how many people have encountered a problem with CORS? Almost no-one, and those that have encountered a problem with CORB and solved it by enabling a shitty CORS that opened the doors. (At least, they're fixing security holes in software that was written by devs who encountered a CORB problem and fuxed it. But all CORS problems follow a CORB problem.)
If we called it by its true name, maybe it would help people understand what's happening. Names are important. If developers understand CORB, they will potentially understand CORS. But no-one can understand CORS till they've understood CORB.
Save a rather short-but-impactful list of exceptions.
> CORS is a mechanism to loosen security, not increase it.
Would that everyone shared your understanding.
Add in these two insights to those we are enlightening:
* CORS is enforced by the browser, so no, your curl command working doesn't say your service is fine
* That error message in the browser about 'no-cors'? It is 99% likely that no-cors is NOT what you want, so the error message is just misleading and unhelpful
...and you'll have covered my CORS wishlist :)
Cross origin requests are allowed (as long as they're simple). Reading the response is what's blocked.