News for hackers. Stuff that matters.
Re:Why do we have both CSRF protection and CORS? by smagin on Monday March 03, 2025 @04:08AM (#43239852)
yup. You didn't imply it but just in case -- this token shouldn't be the same as session token. Session tokens should be `HttpOnly`, so that we don't even expose it to javascript
Re:Why do we have both CSRF protection and CORS? by blincoln on Monday March 03, 2025 @07:35AM (#43241155)
The HttpOnly flag isn't really practical in modern web apps where so much logic runs in JS in the browser and makes requests to APIs. It's a leftover from an earlier era of web app architecture.

If it can be enabled without breaking something, sure, its a good idea, but unless your app is 2000s-era ASP.NET code or CGI script, preventing browser-side JS from accessing the session token will probably break something.

Re:Why do we have both CSRF protection and CORS? by Macha on Monday March 03, 2025 @09:59AM (#43242345)
Right, but if you're doing a SPA, your SPA makes the login call and stores a copy of the session token in local storage, which unlike a cookie isn't automatically sent on any request, never mind cross-origin ones. Doesn't prevent against XSS of course, but then that's what CSP is for.
Re:Why do we have both CSRF protection and CORS? by bastawhiz on Monday March 03, 2025 @10:07AM (#43242447)
It's only necessary to store the login token if your backend is on a different origin than your SPA is served from. It's not especially hard to avoid this.
Re:Why do we have both CSRF protection and CORS? by smagin on Monday March 03, 2025 @10:56AM (#43242956)
You shouldn't need your session token in JS, you can specify your fetch requests to include cookies, and you can setup CORS to allow that.