I think the issue most developers have with CORS is how late in the dev cycle you encounter it. When everything in localhost/http you don't see any issues. It only crops up once you deploy to staging/production environments that are actually on the web. Worst case is when it works fine in staging, and only has issues in production and someone else controls the allow list.
It usually bites you once, and then you look out for it. But about every web developer I know hits it at some point. There used to be footguns of being able to disable CORS, and devs would provide this as a work around. Thankfully browsers have pretty much disabled these settings without intensive investment.
You just reminded me that the project I am about to deploy and ship with a simple `kubectl -f apply` will not ship as fast as I expected. It will feel familiar, and I will not know why :)
Or worst, because I'm somewhat not such a careful programmer sometimes, sometimes the API call will still point to localhost:3000, and I will only notice next day when I want to show my shiny new creation to my significant other from my mobile.
After running back to my laptop so I can fix it, my SO will wonder why am I taking so long and whether am I any good at my "job". I will wonder why the code hasn't updated since the requests are still failing, but the fix was so "simple".
AHA moments later, I'll rush to just copy and paste the first line I find on stackoverflow.
I'll ask myself: Why I still haven't properly learn CORS!? :D
Something I've recently seen more of is people thinking an issue is a CORS issue when in fact it's just an unhealthy service 500ing on the OPTIONS request. I've seen a couple debugging threads get derailed at the start with "this is a CORS issue" because the first person to open a Chrome console scanned and saw "CORS error" on the failed request (I'm guilty of this myself).
I had to deal with this issue about a month ago. It was surprising, as I didn't know that it made the OPTIONS call, and I've been working with webservers and HTML/JS for at least a decade.
I think the edge compute trend is cycling developers away from CORS again.
The old server-rendered frameworks (rails, django) never really needed CORS because frontend and backend were on the same origin.
Then lots of CORS issues cropped up when we started putting React frontends on a separate subdomain from the backend.
But these days, frontend and backend are being pushed onto the same origin again by running compute (or a reverse proxy) at the edge. Next.js is a good example that has baked this practice into the framework itself.
For small sized apps this may be true. For enterprise apps where multiple teams develop multiple features that all end up the same domain, this is still very much an issue. Many enterprise apps need to talk to more than one backend, and you end up with inexperienced developers trying to call remote services from client side code. Or the reverse where you get reqs to create a public api which is basically a proxy for an external service.
From what I can tell, it hits marketers the hardest. They want to be able to drop tracking code everywhere and get frustrated when third party services don’t have * for an allow list and they can’t put analytics in code that is ultimately hosted and ran from a vendors server.
I've strangely not had any problems with CORS. Most of my time is spent wondering why CORS doesn't preflight something, when it's obviously a very bad idea to call it without a preflight. (The answer is: legacy. NCSA Mosaic did something, so Chrome 89 has to do it too. The result is that we spend 6 million person hours on XSRF tokens and carefully-drawn security vulnerability brand assets.)
The issue most developers have with CORS is that on a team, one person solves it for the team's local development and maybe another person solves it for deployments. That is, most of the team never deals with it at all.
> When everything in localhost/http you don't see any issues.
I find the opposite to be true with React dev. You run an api on one port and your react app on another and get CORS errors. In a regular deployment, you just allow origins in the server and all is good. On localhost, every time you change/add a port, you have to allow another origin, play some proxy shenanigans, or run your browser without CORS.
It usually bites you once, and then you look out for it. But about every web developer I know hits it at some point. There used to be footguns of being able to disable CORS, and devs would provide this as a work around. Thankfully browsers have pretty much disabled these settings without intensive investment.