[jrockway]

I think the problem that people are running into with CORS is that their webserver was created before CORS was a thing, so it's tough to configure it correctly. What you want to do is if you allow the provided Origin, echo it back in Access-Control-Allow-Origin.

Envoy has a plugin to do this (envoy.cors), allowing you to configure allowed origins the way people want (["*.example.com", "foo.com"]) and then emitting the right headers when a request comes in. It also emits statistics on how many requests were allowed or denied, so you can monitor that your rules are working correctly. If you are using something else, I recommend just having your web application do the logic and supply the right headers. (You should also be prepared to handle an OPTIONS request for CORS preflight.)

[joecot]

Sure, I wish web servers had better options for this. If you're trying to do it on the web server level it seems like the current solution is a regex with your list of approved origins vs the origin header, and then setting Access-Control-Allow-Origin to the matching one. But the current examples, showing just setting the header multiple times, will lead devs down the garden path. Unless I'm missing something, which I very much hope I am.

[jrockway]

You are right that this article isn't going to enable someone to setup CORS correctly.

It is actually kind of weird that it's in here, because the other things they talk about add more security, but if you don't need CORS and you decide to just add it to your configuration for no reason, you actually now have less security. Especially if you return * for the allowed origin.