3 ms·
I understand CORS and I don't. TL;DR: It's a restriction your browser gives itself. If it's on Domain A and it sees a request going out to Domain B, unless Dom
by ralusek 4mo ago
I understand CORS and I don't.
TL;DR: It's a restriction your browser gives itself. If it's on Domain A and it sees a request going out to Domain B, unless Domain B responds saying that it's expecting traffic from Domain A, the browser prevents itself from making the call.
I think the part about it that is off/silly to most people is that it's not a normal security threat model, because a malicious client could simply just...not impose that restriction on itself. You're perfectly capable of going and curling that same request to that backend, or calling it from an app, or any number of other things. So it's not really protecting your protected resource, the backend, from malicious clients.
All of that is where I feel like I understand clearly. The part I fail to retain is the exact scenarios it does protect against, which IIRC, are basically about attempting to protect your users from being misguided on other clients that are acting as your client, something like that (but again, this literally only applies to browsers). It's just kind of a weird niche problem that I often find myself thinking "I mean why is the user on another client and have allowed themselves to authenticate on that client with my server...this sounds like the user's fault."
- eurleif 4mo agoThe part you may be missing is that cookies exist. User visits A.com, types in their username and password, and a cookie is set in their browser. The browser will send that cookie back to A.com with all subsequent requests, and A.com's server will use it to enable access to the user's account. Now the user visits B.com, which makes a request to A.com/private_user_data. The user's cookie is sent with this request, so A.com will respond with (and B.com will receive) the user's private data without the user consenting to this at all (not even in a "misguided" way).
- xigoi 4mo agoWhy not just not send cookies instead of blocking the request completely?
- 9dev 4mo ago> […] the browser prevents itself from making the call. That's not strictly correct, by the way. The request is made, but the JavaScript code on Domain A is not allowed to read the response. This matters when a request is destructive on its own, for example.
- eurleif 4mo agoTo go even deeper into the weeds: this is only true of "simple" requests[0]. Requests that aren't "simple" always require preflight approval. This is based on which requests a <form> or link could already create without approval; since the dawn of time, <form method="post"> could submit a potentially-destructive request, and sites needed to protect themselves against that via XSRF tokens; so CORS could allow submiting the same class of requests without preflight approval, and not introduce any new attacks. But there's no <form method="delete">, for example, so CORS would have created attacks against previously-secure sites if it had allowed DELETE requests without preflight approval. [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
- ralusek 4mo agoMy understanding was it was an OPTIONS preflight request that is made.
- 9dev 4mo agoOnly for complex requests, and even then - a naive implementation of a web application that executes actions on GET requests might do the same for a HEAD request too.