4 ms·

CORS - or specifically, not permitting cross-origin requests by default - is for preventing CSRF, cross-site request forgery. In particular if the user's creden

CORS - or specifically, not permitting cross-origin requests by default - is for preventing CSRF, cross-site request forgery. In particular if the user's credentials (cookies) are passed along with a request to a third party site, then the first party site can act as the user with the user's authority. In other words, evil.com could e.g. send emails on your behalf by making direct requests to your email provider's web interface.

saagarjha 2y ago
Ok but like why would you pass cookies along
- easton 2y ago
  Because in the 90s/early 2000s someone thought it was a good idea to send cookies for the given site along with all requests (probably a good move, since it would stink to have to tell the browser somehow to explicitly send a cookie for every request, even ones initiated outside of JS). You could say that sites instead must prescribe a "send-cookies-when-requests-are-from-this-site" header, but that's kind of the same thing as CORS.
  - joquarky 2y ago
    We used to rewrite the session ID into all link href and form action URLs for browsers that didn't enable/support cookies. If any link or form did not contain the SID, the app broke. It was tedious.
- dceddia 2y ago
  Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.
Thorrez 2y ago
That's not really correct. CORS and the same origin policy don't protect against CSRF attacks by default, at least if we're using the standard definition of CSRF attacks. An attacker can still "send emails on your behalf by making direct requests to your email provider's" HTTP API even with CORS and the same origin policy in their default settings, as long as your email provider doesn't implement CSRF protection (e.g. anti-CSRF token or Origin header checks). That's why all state-changing HTTP handlers need to implement CSRF protection.

saagarjha 2y ago

Ok but like why would you pass cookies along

easton 2y ago
Because in the 90s/early 2000s someone thought it was a good idea to send cookies for the given site along with all requests (probably a good move, since it would stink to have to tell the browser somehow to explicitly send a cookie for every request, even ones initiated outside of JS). You could say that sites instead must prescribe a "send-cookies-when-requests-are-from-this-site" header, but that's kind of the same thing as CORS.
- joquarky 2y ago
  We used to rewrite the session ID into all link href and form action URLs for browsers that didn't enable/support cookies. If any link or form did not contain the SID, the app broke. It was tedious.
dceddia 2y ago
Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.

Thorrez 2y ago

That's not really correct. CORS and the same origin policy don't protect against CSRF attacks by default, at least if we're using the standard definition of CSRF attacks. An attacker can still "send emails on your behalf by making direct requests to your email provider's" HTTP API even with CORS and the same origin policy in their default settings, as long as your email provider doesn't implement CSRF protection (e.g. anti-CSRF token or Origin header checks). That's why all state-changing HTTP handlers need to implement CSRF protection.