CORS is really hard to wrap your head around, but sadly there's also a ton of developers that not only fail understand the threat model that CORS guards against, they also don't understand webdevelopment in general, especially the http protocol. I find that somewhat strange, because they also can't do native application.
Why would that be strange? Someone who is bad at thing A is likely also bab at closely related thing B.
That's like saying the lock works because people can enter the building. What about keeping the bad guys out, which is the whole point?
You can keep all the "bad guys" out by putting a brick wall in place of every entrance and window. That will achieve 100% of the security goal, and even ops people might breathe a sigh of relief - until the stakeholders who commissioned the buildings get wind of it, that is.
Beyond that, locks aren't about "keeping bad guys out", but about giving owners a degree of control over who can access what and when. "Keeping bad guys out" is a subset of it, possibly a small one, unless you're happy defining "bad guys" as "people whose goals are at odds with the owner's business model".
This is really oversimplifying things, incorrectly IMO, and that sentence makes it sound like you're confusing a CSRF vulnerability with CORS protections. Normally when you write a backend server you implement some sort of authentication and access control, and in that scenario the threat model that lets "an attacker gets one your users to take an action on your site by visiting their site" is a CSRF vulnerability, unrelated to CORS.
The scenario presented in TFA is actually a very special case, because the bug is with a webserver running on localhost that doesn't (apparently) implement access control - not something most web apps entail.
In fact, one of the parts that confuses a lot of people is that CORS rules only prevent the JavaScript web client from reading the response from a remote endpoint - if the endpoint is available on the public Internet then anyone can still make a request to it.
The other thing that is confusing about CORS is that browsers already let you load lots of resources from cross origin servers - you can load images (as TFA points out that Zoom did as a workaround), scripts, stylesheets, form submissions, etc. The one thing you can't do, unless the server implements the appropriate CORS headers, is make a cross origin fetch request from JavaScript.
CORS _additionally_ requires OPTIONS pre-flight to succeed, before allowing any kind of request outside of what can be achieved with a HTML form submit action. So it blocks PUT/PATCH/DELETE, specifying most Content-Type, and specifying nearly all other headers. But this is just blocking "non-standard complex requests that might confuse badly programmed pre-javascript-era servers".
It passes all standard requests that you could have made by: embedding the url as an image src, the target of a HTML form, endpoint for csp reports, etc. All still need to be checked methodically by the server for CSRF if it's going to take any mutating action due to the request.
The browser enforces the same-origin policy by preventing read on non-mutating (i.e. “simple”) request responses and preventing sending of mutating requests (i.e. non-“simple”). CORS provides a protocol for a service to loosen these controls.
It does block ALL requests for certain content types.
In the common cross origin case of a JSON API, CSRF beyond CORS is unnecessary.
To nitpick, it’s the same origin policy that does that.
Assuming the web client plays nicely. I commonly bypass CORS for playwright unit/E2E testing.
It isn’t a knowledge thing (though it could be), or a capability thing, or intelligence. It’s pure mindset.
Ask yourself: is the average person noticing holes in fences and trying random doorknobs… probably not.
But on the other hand, most security people don’t think of product or UX (but some might) so that’s why you have roles.
Yes. Especially kids, and by extension, parents of kids. Also teenagers. And people without means. And clever competition. And people with above-average levels of curiosity. And yes, criminals too.
I'd describe it from a different perspective: most people assume their problems are obviously solvable through an available service, and if they aren't, then either they need to delegate it to specialists or the problem itself is invalid. The minority of people who are into solving problems themselves are, at a high level, hard to distinguish from small kids, teenagers, and criminals, because they all share the characteristic of straying from the journey down the sales funnel, as they're pursuing their own goals and are not interested in getting to the bottom of that funnel.
It’s because CORS builds on a very odd base permission model. So if you use multipart form data, okay. But application JavaScript bad.
CORS literally exists only against XSS and CSRF for actively logged in human users. Anything else in CORS is absolutely pointless because every other attack scenario uses scripts or programs that fake HTTP headers anyways. It's just as useless as the Sec-CH (client hint) headers because some Browser made by a company that starts with Micro and ends with Slop decided that the User Agent always needs to be Windows 10 for compatibility reasons.
That is why you see everyone just enabling every CORS option anyways, even though that is literally the worst case that allows XSS and CSRF. And a lot of websites have user edited content at some place, at the very least in images that aren't filtered for embedded scripts (PNGs, anyone?).
Client hints are useful for all the shitty “responsive” websites that don’t know how to use media queries. And for ad tracking. Mostly the latter
Exactly what I need. My API is public I just don’t want someone other than my own website to consume it. Is it that hard to understand?
They just want to prevent hotlinking/leeching.