CORS is such a mess. What are current best practices?

1 year ago

source link: https://lobste.rs/s/2qr2nf/cors_is_such_mess_what_are_current_best
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

I’m looking into implementing CORS (again, it seems like this is something that comes up every few years, and every few years I have to re-orient myself about how it all works), and as always it’s so confusing. (Here I’m talking about Access-Control-Allow-Origin type stuff, primarily, as CORS was initially a structured way to relax the same-origin policy on requests. I’m not as familiar or concerned with some of the newer headers for mitigating Spectre-type attacks. Should I be?)

Any CORS experts out there with “best practice” recommendations? The security and threat model is so counterintuitive.

Is the whole point of the CORS model basically to handle the browser’s decision to send cookies on every request? If the browser just refused to send cookies by default on non-same-origin requests and prompted the user to “Allow Once” or “Allow Always” like it does for saving passwords, wouldn’t that also solve the problem (and not to mention CSRF as well, which CORS doesn’t address).

The server needs to handle arbitrary traffic from arbitrary clients, so resources should be protected appropriately. The only thing particularly unique about the browser is that it chooses to send cookie credentials, possibly against the user’s intentions.

With all that in mind, it seems like these are maybe best practices (somewhat counterintuitively):

When possible always set Access-Control-Allow-Origin: *. Everywhere online seems to recommend not including the header, if it’s not necessary, or being as specific as possible with the origins you allow and validating against a regex or an allowlist. But, since ACAO * does not allow credentials, then that’s actually safer, right? And if your backend has to expect traffic from, say, curl, or whatever, then you might as well acknowledge that fact fundamentally and say arbitrary JS scripts out there can also hit the endpoint (as long as, similarly to curl, they don’t include a cookie). Is there a downside to this approach?
Access-Control-Allow-Credentials: true - this is the truly dangerous one, since the whole threat model of CORS is about a malicious website sending an authenticated request to your server without the user’s consent. So in this case, you do need to carefully set ACAO to specifically the origin that your own real site is at.
What should you do about CORP, COEP, etc - all the new headers?

Recommend

127

微信 mp.weixin.qq.com 6 years ago
Cache

[译] 理解 CORS

195

itnext.io 6 years ago
Cache

CORS — Understanding it practically – ITNEXT

Cross-Origin Resource Sharing (CORS) is a mechanism that uses additional HTTP headers to let a user agent gain permission to access selected resources from a server on a different origin (domain)…

114