engineeringdept
Proposal to migrate to tokenless/header only CSRF in Plug/Phoenix
In 2026 double submit/session tokens are no longer necessary to prevent against CSRF attacks. Instead, we can use the Sec-Fetch-Site header, with a fallback of the Origin header. This has a couple of advantages:
- Removes a whole class of easy-to-make mistakes around CSRF token handling - e.g. accidentally not passing a token through to a JS request
- Removes any issues related to long-lived CSRF tokens in non-cookie session storage - e.g. a user returning to the site after their CSRF token has disappeared from the Redis backed session storage and their next actions failing
This blog post does a good job of outlining how to prevent against CSRF attacks using these headers and the issues around legacy browsers. It has been adopted in Go 1.25 in the net/http middleware.
I’ve had a go at implementing a Plug which does same: GitHub - breakroom/plug_cross_origin_protection: A Plug to protect against Cross-Site Request Forgery (CSRF) attacks using modern header-based checks instead of tokens · GitHub (this is not yet in production, but likely will be after more thorough review.)
Is there any interest in adopting this approach in Plug/Phoenix and dropping CSRF tokens ( Plug.CSRFProtection — Plug v1.20.2 ) entirely? Or should I continue with a separate library?
Most Liked
josevalim
Ship your thing and collect feedback! That will be useful for upstreaming it later when the time is right!
LostKobrakai
I was looking at the readme. I don‘t think the skip example is correct. The plug in the controller would only run after the plug in e.g. the router pipeline. So you‘d store the intent to skip after the skippable plug already executed.
I‘m also curious about the exception. Imo an exception should be the default with a Plug.Exception integration to turn it into a 403 (e.g. have a plug_status field of 403). That‘s how plug itself handles that.
I also see you using the Plug namespace. Before publishing you‘d want to change that to your own namespace: Library Guidelines — Elixir v1.12.3
derek-zhou
I use Origin header alone in production. Besides what you mentioned, there is at least one more problem with CSRF tokens nowadays because:
- I store all session data server-side and only set a random key as the session cookie. (pretty common practice)
- I have forms in public accessible pages (pretty common practice)
- Bots are pounding those pages non-stop ((what can I say?)
By not generating and storing CSRF tokens, I avoided thrashing my session storage.
Popular in Proposals: Ideas
Other popular topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Practical resources that improve the lives of professional developers.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking for Elixir devs who love to ship. Start your free account.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"