The csrf token is ideally tied to your session. If it's anonymous, Eve didn't need Alice to visit a page in the first place. If it's tied to a session, Eve can't create a working token for Alice.

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

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.

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.

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.

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.

Traditionally csrf tokens had two parts: something in a cookie(/server side data store that used a cookie as the id), and something in a form element on the page.

So while an attacker could trick your browser to making a request to get the cookie, and trick your browser into submitting arbitrary form data, they couldn’t get the csrf tokens to match.

The CSRF token is usually stored in a cookie. I guess one could try stealing the cookie assuming the CSRF token hasn't been consumed.

But if one's cookie happens to be stolen it can be assumed they already have access to your session in general anyways making CSRF moot.