Do we still need CSRF protection in Rails 8?


maybe it’s controversial or I’m having a misunderstanding about SameSite Lax, but I’ll ask anyway:

With most browsers supporting SameSite Lax cookies, I was wondering if we still need the different CSRF protection mechanisms in Rails? With the new Rails 8 default to even block non-modern browsers it feels like there’s even less of a chance that old browsers are using a Rails app.

Not having to send all the CSRF tokens would simplify some things:

  • Easier caching with etags
  • Less automatically generated sessions generated by Rails (ActiveStorage recently introduced a DisableSession concern to skip session cookies to allow caching with CDNs more easily)
  • No X-CSRF-Token header needed in AJAX requests
  • Not having to worry about per form-tokens for BREACH mitigation

One downside on only relying SameSite lax would be that would be able to execute requests against by default, which would not be the case today with CSRF tokens. Maybe this downside is bad enough to keep the protection mechanisms?

I’d be interested in other opinions about this topic :slight_smile:


Similar questions were asked on Information Security Stack Exchange here and here. The answers note that SameSite Lax doens’t protect against:

Also, relying solely on SameSite Lax means trusting that modern browsers will never introduce a bug where they mismanage cookies. It’s probably good to keep a layered security approach and continue to use CSRF tokens.


Thank you for your reply and linking the relevant SE posts!

I can see your argument for a layered security approach. Default security measures to protect against potential future browser bugs feels a little bit too fearful (for me). I understand the argument for the subdomain CSRF protection though!

I think an approach in future could be to handle CSRF in a similar way to CSP headers in Rails. Generate a commented out configuration where you can opt in if you want to have additional protection.

1 Like