Hacker News Reader

Comment by barrkel | Hacker News Reader

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.

View on HN

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.

Ok but like why would you pass cookies along

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.

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.

Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.

Reply on news.ycombinator.com