On the contrary: CORS is what enables other sites to use your resources (in a way allowed by your policy). It was created because, by default, browsers don't let you do that.

I think what GP commented is a very common misconception. CORS is not the source of the developer trouble (that would be cross-origin restrictions), it is a way around them. But it is perhaps understandable where the confusion comes from... Browsers always mention CORS headers as part of error messages, after all.

+1 - This is a large part of the trouble. It leads to a lot of stuff being defined as the inverse of some other behavior - behavior that the developer does not have control or understanding of.

But only one domain at a time. The lack of a way to specify multiple domains in a header makes it absurdly painful to actually implement when you want to make your content available to a specific set of domains.

I’m personally at the point where I’d rather handle unnecessary request authentication than trying to do anything with CORS.

I'm curious, why was it painful? We just had a middleware do an Origin check and copy the header if it matches.

90+ microservices with 5+ environments. Mostly a matter of scaling a solution across a rather large surface area and across a number of languages and teams.

Fair enough; seems like it could be done using a gateway like Kong, but if you're not already using one, it wouldn't be worth adding it just for that.

Back in the day, we used to use some Apache redirect magic to redirect to, say, an image of our choosing when the Referrer header was wrong. I had a relatively polite 'hey, you can see this image here:' message. Other people redirected to less friendly things.

You can still do this. The Referer header is sent by default on requests, and you can make your server interpret it to do anything you want.

This is true unless the referring URL is secured (HTTPS), and the destination URL is not. In that case a conformant user-agent will leave Referer out.

https://tools.ietf.org/html/rfc7231#section-5.5.2

True, though you should run HTTPS on your site. Which means you'll get the Referer unless the other site or the user's browser has been configured to suppress it.