The author hasn’t clarified yet, but I suspect what they’re referring to is the fact that CORS does not support granular access control. If you make something public under CORS, any client can retrieve the resource if no other authorization or authentication check is in place. It’s not a system of authentication, it’s a system of authorization - specifically, for authorizing hosts to request resources which normally wouldn’t be authorized to do so under same origin policy.

As a concrete example: people occasionally misuse the Origin header, thinking that they can use it as a form of client authentication. The idea is that any client request from a non-whitelisted origin will fail. But any user can spoof their own Origin header, and the Origin header is primarily intended to protect users from making CORS requests they didn’t intend (because in most cases an attacker cannot coerce a browser to forge a header).

CORS is not a tool to turn resources private, but to protect the browser (not the server's content) from cross domain requests.

Exactly, the attacker can always not use the browser and emulate a browser request if motivated enough.

Yes, that's precisely why CORS is a poor fit for authentication :)

Sure, but I don't see why the tip in OP is "don't use CORS". To me that implies there is actually something insecure about using it.

Yeah you can use CORS securely, there are just pitfalls to look out for.

Wondering about the same thing.

Some people have performance concerns with CORS is the main reason I believe. The overhead is an extra round trip.

I thought the concern was security.

Anyway HTTP2 would hopefully address that (through header compression), and things like zero-RTT TLS and keep-alive further minimize the overhead of an additional request.

Plus doesn't CORS only make preflight requests periodically, not for every request?

I wrote/research a lot about http/2, and even has a small tool for it (https://http2.pro).

Among many things you get from http/2, it cannot eliminate round trip time. Sure, you can keep a connection alive but that's possible with http 1.1 too.

Header compression is HPACK. If the header changes even the slightest bit, it's not cached. Dynamic URLs and headers can easily bust HPACK compression.

Preflights are cached, but because CORS is per-URL caching can be of limited value. If your API uses `/info` and `/edit`, a preflight request has to be made for both (assuming a preflight is necessary). If your application has dynamic URLs (e.g. `/widget/1`, `/widget/2`, etc.) the problem is exacerbated even further.