News for hackers. Stuff that matters.
Re:Claude's API now supports CORS requests, enabling client-... by barrkel on Friday August 23, 2024 @05:16AM (#41327429)
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.
Re:Claude's API now supports CORS requests, enabling client-... by saagarjha on Friday August 23, 2024 @07:33AM (#41328067)
Ok but like why would you pass cookies along
Re:Claude's API now supports CORS requests, enabling client-... by easton on Friday August 23, 2024 @09:25AM (#41328819)
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.

Re:Claude's API now supports CORS requests, enabling client-... by joquarky on Friday August 23, 2024 @07:01PM (#41333831)
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.

Re:Claude's API now supports CORS requests, enabling client-... by dceddia on Friday August 23, 2024 @10:41AM (#41329435)
Just to add to the sibling comment - you don’t get a choice to pass cookies or not, the browser just includes them automatically.
Re:Claude's API now supports CORS requests, enabling client-... by Thorrez on Friday August 23, 2024 @10:07AM (#41329159)
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.