Login CSRF (Session fixation) attack

[bbaterdene-gh]

How does this approach effectively prevent login CSRF(session fixation) attacks without reintroducing full CSRF protection on login endpoint?
I’m trying to understand how it blocks unauthorized cross-site login attempts while maintaining good UX.
See the Epic Stack decision here:
https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions/035-remove-csrf.md

and this article on login CSRF UX issues:
https://support.detectify.com/support/solutions/articles/48001048951-login-csrf

Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

[kentcdodds]

Hey! Great question. This is something we considered carefully.

Epic Stack uses SameSite=Lax for all cookies, which means browsers won’t send cookies on cross-site POST requests. That’s the main vector for CSRF, so this configuration effectively blocks classic CSRF attacks.

For login CSRF/session fixation: our /login endpoint doesn’t require cookies to be sent with the request, so an attacker can’t force a user to log in as someone else via a cross-site request. The only way to exploit this would be if the attacker already knew the user’s credentials, in which case they could just log in directly.

If we ever change our cookie config (e.g., to SameSite=None) or add GET endpoints that mutate state, we’d need to revisit this. But with our current setup, removing CSRF tokens is safe and keeps things simpler.

More details in our decision doc as you linked: https://github.com/epicweb-dev/epic-stack/blob/main/docs/decisions/035-remove-csrf.md

Thanks for raising the concern!

[bbaterdene-gh]

@kentcdodds
Thank you for the thoughtful response. Let me clarify my concern a bit further.

Yes, using SameSite=Lax is definitely effective at mitigating most classical CSRF attacks, especially for authenticated POST requests that rely on cookies. That part is solid.

However, I’m specifically referring to public POST endpoints, particularly the /login endpoint, which does not require any credentials to be sent with the request. This opens up a potential for login CSRF, also known as session fixation.

Consider the following attack scenario:
1. An attacker creates an account on epic app and obtains a valid session.
2. The attacker then crafts a POST form that submits their own username and password to the /login endpoint.
3. They trick a victim into visiting a malicious page that automatically submits this form.
4. The victim’s browser executes the request, and server sets a session cookie for the attacker’s account.
5. The victim is now unknowingly logged into the attacker’s session.

Even though no cookies are required to be sent with the request (so SameSite=Lax blocks nothing here), epic app sets a session cookie as a result of that login. From the victim’s perspective, they are now logged in—but under someone else’s identity. If they do not notice (and most users will not), this leads to confusing and potentially dangerous behavior. For example, an attacker might retrieve anything the victim does while logged into that session—search history, profile changes etc.

This is the same class of issue Google once faced.

Another, less obvious, example is a login CSRF that once existed in Google, which made it possible for the attacker to make the user log in to the attacker’s account and later retrieve all the searches the user had made while logged in.

I understand and agree with the motivation to simplify the stack and avoid full CSRF protection everywhere. However, I would suggest treating the login endpoint as a special case. It is public, it changes authentication state, and it has no CSRF protection under the current setup.

One lightweight and effective approach could be to add CSRF protection only to the login endpoint. That would protect against this class of attacks without reintroducing complexity across the app.

From a user experience perspective, this kind of attack is especially frustrating because the user likely has no idea anything went wrong. They just end up logged in as someone else, and it can take a long time before they realize it.

So again, the overall design is strong and well-considered. I just think public POST endpoints, in this case the login route, deserves this small extra layer of protection to avoid a very confusing and subtle failure case.

[bbaterdene-gh]

@kentcdodds

For login CSRF/session fixation: our /login endpoint doesn’t require cookies to be sent with the request, so an attacker can’t force a user to log in as someone else via a cross-site request.

The attack does not rely on cookies being sent with the request. It relies on the fact that server sets a session cookie in the response. That means an attacker can still trick a user’s browser into submitting a cross-site POST to /login using the attacker’s own credentials. If the login succeeds, the browser receives a session cookie — authenticating the victim as the attacker.

Example flow:

1. Attacker creates an account, gets a session.
2. Attacker crafts a form:

<form method="POST" action="https://epic-app.com/login">
  <input name="username" value="[email protected]" />
  <input name="password" value="password123" />
</form>
<script>document.forms[0].submit()</script>

3. Victim visits attacker’s site → browser submits form to /login.
4. Server sets a new session cookie in response.
5. Victim is now authenticated as the attacker — session fixation.

This is possible even if the login request is cross-origin and has no existing cookies. The critical point is that the server responds with a Set-Cookie, which the browser stores.

SameSite=Lax does not prevent this because it controls sending cookies, not receiving them. So this setup does not block login CSRF.

[kentcdodds]

This is a very good point! I would be willing to accept a pull request to add CSRF protection for the login form. Thank you for bringing this up.

[bbaterdene-gh]

@kentcdodds
I’ve been wondering—would restricting the /login endpoint to accept only Content-Type: application/json effectively prevent login CSRF/session fixation attacks? Since browsers cannot submit cross-origin requests with JSON payloads via forms, would this block forged login POST requests without needing full CSRF tokens?

What is the trade-off here? It seems like a lighter-weight solution compared to introducing CSRF token on the login endpoint. Also, does this approach support a good user experience on the login form, especially for non-JavaScript or slower clients (It seems like a good solution for SPAs)?

Would love to hear your thoughts on how this balances security and UX in practice.

[kentcdodds]

Doing this would mean that users with slow network connections may try to submit the form before the javascript loads and it wouldn't work. I'd rather do the CSRF thing.

[bbaterdene-gh]

@kentcdodds
I wanted to use remix-utils but I have a few questions about the CSRF protection implementation, so I raised a discussion here:
sergiodxa/remix-utils#504

"Users with slow network connections may try to submit the form before the JavaScript loads and it wouldn't work. I'd rather do the CSRF thing."

I agree with that concern, but my question is somewhat unrelated to Epic Stack.
If the setup is a React Router SPA plus API, and it uses cookies for auth just like Epic Stack, and CORS is configured appropriately, then:

• The SPA depends on JavaScript loading to render the form.
• If the /login endpoint is restricted to accept only Content-Type: application/json, that effectively prevents login CSRF attacks.

Do you agree with this approach?

[kentcdodds]

Yes, if you have a React Router SPA (or any JavaScript-powered client) and your login endpoint only accepts requests with Content-Type: application/json, that does effectively prevent login CSRF/session fixation attacks. The reason is that browsers can’t submit cross-origin POSTs with JSON payloads using plain HTML forms—so an attacker can’t trick a user’s browser into logging in as the attacker via a form POST. This is a solid, lightweight mitigation for SPAs where you control the client and can guarantee all logins go through JavaScript.

The main trade-off is that it breaks progressive enhancement: users without JavaScript, or whose JS hasn’t loaded yet (slow connections, script errors, etc.), won’t be able to log in. For a pure SPA, that’s usually an acceptable trade-off, but for frameworks like Remix (or anything aiming for robust, JS-optional UX), I’d still recommend CSRF protection on the login endpoint instead. That way, you get both security and a good experience for everyone.

So: for SPAs, restricting to application/json is a good, simple fix. For progressive apps, CSRF tokens are still the best bet.