I still don't understand the threat model and, obviously, it's not explained here either.
I log in to social.net. I click on scam.org and change sites. I'm on scam.org and it triggers a request to social.net/friends.
No cookies are sent, no JWT. I'm not logged in and get a "Needs login" HTTP error. Nothing bad happens.
I thought that's how it works without CORS already.
CORS relaxes the rules about what requests the browser can make.
The server doesn't get to stop the browser making calls that it didn't want, so it's a browser security feature, to stop the browser sending cookies where it shouldn't, or more precisely, to only send authentication and other info where it should.
It relaxes the same origin policy.
Usually a browser will not load resources from another origin based on the HTML it receives. If the page is from example.com, it won't allow you to load a page from example.org.
That stops things like authentication and cookies etc from example.com being transmitted to example.org if someone hacks the webpage.
CORS allows the server to relax those rules so that it can say "You can load resources from me, or from these other servers."
So it can say "I'm example.com but you can load resources from example.org and that's OK."
At least, that's how I think it works :)
Cookies will be sent if SameSite=None. Because a lot of the web's security features were implemented well after the tech was popular it's a patch-work with lots of overlap.
By default cookies are sent for cross-origin requests. The SameSite cookie flag that lets sites control this was only shipped in Safari the year before this blog post was written so it would have been hard to depend on it yet.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Coo...