CSRF protection built into Remix

[JasonEtco]

Hello! Was just chatting with @kentcdodds about CSRF protection in Remix - it's a lightweight feature that some frameworks (like Rails) have built-in to protect against "Cross-Site Request Forgery":

A CSRF attack targets Web applications failing to differentiate between valid requests and forged requests controlled by attacker.

Would definitely recommend reading up on it, but the basic concept is that on a GET that returns some HTML, the server generates a random token and stores it on the requester's cookie (or sometimes just a meta tag). That token is included in every subsequent POST (usually via an <input type="hidden" name="csrf" value="<generated_token>"> or as a request header). If that token is not present or isn't valid, the request is denied.

That's a level of protection that Remix can include without any additional work from the developer! There's already a great approach from @sergiodxa in remix-utils: https://github.com/sergiodxa/remix-utils#csrf.

But, it'd be great if Remix just included the token in every POST by default. This would make Remix more secure by default, making all Remix apps "just more secure" 🎉 There could potentially be a way to disable CSRF entirely (maybe via remix.config.js?) - but that's an implementation detail.

Happy to chat through it more!

[MichaelDeBoey]

I like this idea very much that Form could include this by default.

The only thing I’m wondering is: what if you have next to your web part a mobile app that’s using the same endpoints? How would the mobile app get a valid CSRF token?

[kentcdodds]

You'd just disable the feature if that's what you want. I'd say a very small number of people will do that. We can solve that problem when it becomes one though.

[sergiodxa]

In Rails, by default it uses CSRF, but if you want an action to don’t have that there’s a way to tell Rails to don’t validate that on those cases.

[JasonEtco]

Since this doesn't seem super controversial, I figure a straw-man PR is a good next step (but no rush, happy to keep discussing it). Anyone is welcome to open a PR for this, but my plan so far is:

• Figure out the best place to create the CSRF token - for example, the csurf Express middleware sets it on a cookie on every request. remix-utils provides methods to do it yourself, and ideally Remix would call similar functions internally. I'm not quite sure where yet though. Pointers appreciated 🙇
• Check for the token in remix-server-runtime/handleDataRequest; this would apply to every [POST, PUT, PATCH, UPDATE] request, which I think is a good thing.

On the topic of what "options" folks might be able to set for their CSRF protection - I'd suggest none 😊 IMO, this should be something that Remix just does, and if its not tuned to exactly what the developer needs (ex: wrong cookie name) they can just disable it and roll their own.