From my experience, the reason CORS is hard to understand is that it's somehow inverted from the default form of "security".<p>We easily form the intuition of the client being a by-default untrusted entity, and checking whether it has the privilege of accessing this data, where the server is the arbiter of that access.<p>CORS is so inherently different to that, and while the information is easily available, it requires a short but careful read to grok the idea -- which a dev tunnel-visioning towards getting their application code written may not wish to slow down for.
It's not just CORS that's hard to understand. Many (most?) developers don't really understand the threat model. And even when it's explained it hard to see why it's a big deal. Part of this is that backend developers usually have to configure CORS and it's not an access privilege protection. From the point of view of the backend it doesn't seem to matter. Bad guys can't get it. From the point of view of the front-end it's often seen as a nuisance.<p>The article does a nice job giving a concrete example.
The only thing I remember about CORS is that it takes way longer than expected to debug, by design the error messages sent to the browser are intentionally gutted, and CORS error scenarios are hard to tell from other failure modes atfirst glance.
> <i>by design the error messages sent to the browser are intentionally gutted</i><p>A CORS error is not "an error message sent to the browser", it is an error generated by the browser, because the browser has decided it cannot permit the request. (Though certainly a server can not understand a CORS request as such, and returned a weird response, which would then end up getting translated to a CORS failure.)
Sometimes I'm not even sure what I truly 'understand.'
When even senior engineers working on products used by hundreds of millions of people, like Zoom, have had these kinds of issues, it makes me wonder. So I usually just write code the way it was left by my seniors, out of inertia. But I realize that the area I work in is actually incredibly abstracted.
Generally when I'm debugging these, I need/want to know what was the preflight (if applicable), and was the preflight what was expected? When I help <i>others</i> debug these, generally I find there is little expectation of what the preflight "should" be, and instead just a bunch of stochastic attempts to adjust the server's response headers to get the browser to capitulate — regardless of whether that makes any sense at all.<p>I would also say I think Firefox's network inspector is better in this area. (But I'm often having to ask others to "no, don't send the failing request, send the CORS preflight", we need to understand what happened with it.)<p>> <i>Anecdotally, lots of developers I’ve talked with don’t understand well how CORS works.</i><p>Yeah, most FE devs I've worked with seem to not understand CORS.<p>> <i>Is the CORS API too complex and confusing</i><p>I think it can be hard if you don't understand why the exceptions to preflights are what they are, but the moment you internalize "because the browser can already emit that request in other cases" then it becomes <i>obvious</i> what categories are what & why.
I honestly just can’t be arsed. I write the code to do the thing I want, and if CORS throws a wrench into things, I make Claude fix it for me. I’m tired boss.