tme_317
Is CSRF mitigation necessary when using plug sessions/cookies for auth with Absinthe?
I was wondering if you decide to use sessions (typically using cookies) to store the auth token using Absinthe.Plug :before_send option like in the example here: Access to Plug.Conn in a processing pipeline · Issue #109 · absinthe-graphql/absinthe_plug · GitHub if you open yourself up to CSRF attacks on subsequent query/mutation POST requests?
It’s simple enough to store a CSRF token in the page and submit it as a x-csrf-token header in the query/mutation for validation but not sure if it’s necessary to worry about it. Also not sure exactly how to deal with CSRF token staleness/refresh/reuse issues if needed in multiple queries/mutations on the same page. I could add a request for a new fresh token after every post as part of my GraphQL query but it’s a bit tedious and maybe there’s another better way?
Marked As Solved
jeremyjh
CSRF protection is recommended for all web requests types. It does not matter that the payload is a GraphQL message. By default tokens can be re-used. A typical SPA would use the token received in its initial page load for all requests until that page is refreshed again.
Popular in Questions
Other popular topics
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
- #performance









