CSRF protection

[mwcampbell]

Since Remix encourages the use of classic HTML form posts, I wonder if it has any sort of protection against cross-site request forgery. If so, I couldn't find anything about that in the docs.

[mwcampbell]

I'd still like an answer to this question. I won't be comfortable using Remix for a serious project until I know I can protect users from CSRF. Thanks.

[benwis]

I'll take a stab at answering this. The answer is that, even with classic forms, protection from CSRF falls on you to implement. Remix could do it for you, but since we have a number of implementation choices your mitigation might be different. Still, updating the docs on release would be helpful.

Essentially for CSRF attacks you need three things:
Form Actions. There is an action within the application that the attacker has a reason to induce. This might be a privileged action (such as modifying permissions for other users) or any action on user-specific data (such as changing the user's own password).
Cookie-based session handling. Performing the action involves issuing one or more HTTP requests, and the application relies solely on session cookies to identify the user who has made the requests. There is no other mechanism in place for tracking sessions or validating user requests.
No unpredictable request parameters. The requests that perform the action do not contain any parameters whose values the attacker cannot determine or guess. For example, when causing a user to change their password, the function is not vulnerable if an attacker needs to know the value of the existing password.
Copied from https://portswigger.net/web-security/csrf

So let's talk about Remix here. We definitely have #1 with form actions. Not much to do there.

#2 Cookie based session handling: Remix provides multiple ways to do session handling. If you use cookies, you can protect against this by setting SameSite=Strict on your session cookies. This prevents all requests coming from third party sites from attaching your session cookie, and you're safe. If you're using file based sessions, the session ID is the only thing stored in the cookie, and essentially acts as a CSRF token, since the session ID is also in the file on the server. You probably still need to check the two match when you call an action. Same thing if you implement database session storage.

#3 No unpredictable request parameters: This one is up to you to implement, but you have options. If you're using cookies you should set sameSite=Strict in production, or have your Remix server generate a unique per user session CSRF token, and include that in your form as a hidden field. Then check that its valid in your form action. With file based or db based, you can implement CSRF token checks in your actions and store the token server side.

Either way, assuming you behave responsibly, there is no reason Remix is more vulnerable to CSRF because of regular form actions. As I mentioned earlier though, the docs should be updated to discuss this, and I'm sure they will be once we've hit 1.0

[davidbarratt-drizly]

I'm shocked that this web framework uses HTML Forms, but does not protect against CSRF attacks by default. To make matters worse, the documentation does not even mention this. Where it does mention it, it is completely wrong

First, the new logout route is just there to make it easy for us to logout. The reason that we're using an action (rather than a loader) is because we want to avoid CSRF problems by using a POST request rather than a GET request. This is why the logout button is a form and not a link. Additionally, Remix will only re-call our loaders when we perform an action, so if we used a loader then the cache would not get invalidated. The loader is just there in case someone somehow lands on that page, we'll just redirect them back home.

To reiterate for those in the back, using a POST does not in any way prevent a CSRF.

I'm a long time user of frameworks like Symfony who provide CSRF protection out of the box and on by default. You have to explicitly disable the protection on a per-form basis. This is similar to React's built-in XSS protection and their extremely verbose method of bypassing it.

The above comment is also incorrect because it assumes that I'm running a site on the internet rather than perhaps an intranet.

Let's say I build a form for Example, Inc.'s internal intranet and it's hosted at https://deleteemployee.corp.example.com, and it's only accessible if you are on example.com's corporate VPN. Since I know that is the only way to access it, I don't bother to build a login system (why go to that effort?) and Remix is great so I use that for my framework.

Well one day I get an email to my personal email that all of our employees have been deleted from our database! How is that possible?

Well... come to find out, one of our employees went to a competitor's website to do some price comparisons, they had a little snippet on their site that looks like this:

fetch('https://deleteemployee.corp.example.com', {  method: 'POST', body: '...' });

while they weren't able to read the response with JavaScript, the browser happily executed the request since it met the qualifications for a simple request.

There are really only a few ways to protect against this:

1. You could have the server enforce that incoming POST requests do not meet the criteria for a simple request. For example, by enforcing a Content-Type: application/json header. Of coursse this would force JavaScript to be used for form submission.
2. Setting a cookie (SameSite=Strict) on the HTML page that has the form, that contains a signed token (a JWT?) that is verified on the POST request.
   a. If you want to support older browsers (SameSite=Lax) you could also include a CSRF token in the form POST (as a hidden field) that is validated against the cookie. This is safe because in my example, even if the browser submitted the cookies, the attacker wouldn't be able to read the HTML page in order to get the hidden form value (though this value would need to be unique per request and tied to the cookie)

If 2 is implemented, it needs to be well documented that the cookie should be excluded from caching decisions. You wouldn't want someone to always bypass the HTTP cache just because they happened to land on a page with a form.

I can't recommend that anyone use this framework until this is fixed. Yes, engineers do (on occasion) need a way to opt-out of these protections, but by default they should be there.

I'm really hoping this is resolved quickly because Remix does seem really great and I'm excited to make something with it!

[probablycorey]

To reiterate for those in the back, using a POST does not in any way prevent a CSRF.

If the cookie is using SameSite=Strict or SameSite=Lax, using a POST will prevent other sites from being able to access this endpoint, right? So in that specific case, it does prevent a CSRF (on the 96% of browsers that support SameSite)

[mwcampbell]

Perhaps Remix is relying on the SameSite feature of cookies, now implemented in all modern browsers, for CSRF protection. That would be in keeping with the theme of being built on modern web fundamentals.

[davidbarratt-drizly]

Perhaps Remix is relying on the SameSite feature of cookies, now implemented in all modern browsers, for CSRF protection. That would be in keeping with the theme of being built on modern web fundamentals.

If that's the case, then it should be made explicit in the documentation, but in my example above, the SameSite attribute is irrelevant if it's not setting/validating a CSRF cookie in the first place.

[rphlmr]

Maybe it could help someone :) https://sergiodxa.com/articles/adding-csrf-protection-to-remix

Package here : https://github.com/sergiodxa/remix-utils

[ngbrown]

If using OAuth to start an authenticated session, one often has to use SameSite=none to get everything to work because of the redirect flow. Which prevents using the same cookies for CSRF in forms...

[katlyn]

It's important to note that SameSite cookies cannot be relied on for CSRF protection at this point in time. While 96% of browsers do support the SameSite cookie attribute, the 4% of browsers that don't will treat SameSite cookies as regular cookies; as a result voiding any protection that the SameSite attribute might have had. In addition, only 75% of browsers default to SameSite=Lax, leaving 25% still defaulting to SameSite=None.

I'd strongly echo the sentiment of others here that have said that should be implemented by default as part of Remix. At the very least, it needs to be documented if Remix plans on relying on the SameSite attribute for CSRF protection - without further changes, I would definitely not consider the SameSite attribute to be reliable enough to be the only protection against CSRF attacks.

There's some additional information on how effective the SameSite attribute is in this security stack exchange question that might also be interesting to some folks.

Statistics last updated 2024-07-15.

[Konstantin-tr]

Is there any plan to make CSRF tokens a default behaviour for forms? Coming from an SPA background and not using forms in a while, I honestly wouldn't even have considered this issue until stumbling upon it again today. For big frameworks, you kind of expect basic security concerns like this to be mitigated by default...

[ben-polinsky]

At the least there should be a section in the docs about it. All security is about tradeoffs in usability. They should explain their thinking if they believe it is not vital.

[brookslybrand]

I saw a question about CSRF in Remix asked in the roadmap planning livestream today.

Just wanted to follow up and say that @davidbarratt-drizly was right that this should have been called out in the documentation. It was added in August 2022 (over a year ago)

Docs

[ProtonGustave]

But SameSite=Lax won't protect from CSRF attack when user being redirected to website using form, it's not tricky to implement

[ProtonGustave]

form POST from attacker domain, yes, it will navigate user to vulnerable website and will be considered as top level navigation. SameSite=Lax will send cookies in that case

https://datatracker.ietf.org/doc/html/draft-west-first-party-cookies-07#section-3.2

[kevlened]

I see. It does indeed seem like a gap. If the default were SameSite=Strict, this wouldn't be an issue. SameSite=Lax is now the browser default, and recommended for content sites, but SameSite=Strict is recommended for web apps.

We recommend using SameSite in this way, setting cookies that affect website display to Lax, and cookies related to user actions to Strict (source)

The default can be overridden by a remix user when creating the cookie storage, so adding a note to the CSRF doc seems prudent.

[ngbrown]

form POST from attacker domain, yes, it will navigate user to vulnerable website and will be considered as top level navigation. SameSite=Lax will send cookies in that case

https://datatracker.ietf.org/doc/html/draft-west-first-party-cookies-07#section-3.2

Cross-site navigation with a form POST does not normally include cookies that are marked as SameSite=Lax. I've experienced this first hand when authenticating through use of the Microsoft Authentication Library (MSAL). When my application redirects to login.microsoftonline.com for authentication and Microsoft displays any prompt for the user, then the POST back to the application does not include the session cookies. On the other hand, it isn't considered a top-level navigation if the redirect starts at my app, and without a prompt, immediately generates a POST back to the application without any interaction. In this case, the bounce includes the cookies (because the user already has a valid Microsoft session).

Having said that, I still implemented a stable CSRF token for the life of the user session and the token is used for form submits as this is all that is required in the recommendation by OWASP.

[ProtonGustave]

What do you mean by normally? Firefox and Chrome includes cookies with SameSite=Lax for cross-site form POST

Changing SameSite to Strict is not a drop-in replacement because it requires changing session management, otherwise it will break things

[ngbrown]

What do you mean by normally? Firefox and Chrome includes cookies with SameSite=Lax for cross-site form POST

This statement does not align with what I have seen myself (in both Firefox and Chrome) or what I understand the spec to be. Can you provide or point to a working concept for a cross-site POST with a SameSite=Lax cookie? Say between Vercel and Netlify or Cloudflare preview sites (to ensure different origins). I would be interested to see it in action.

There are some nuances around what is a top-level "cross-site" vs "same-site" navigation, as I partially explained above, but otherwise the browsers consider POST an unsafe method for cross-site cookies.