How to handle user experience of CSRF token rejection

Viewed 35

I'm working on a Silverstripe-graphql project that comes with baked-in CSRF token protection for forms.

Here's where I've been looking to understand CSRF:

Current UX issue
Currently, if a user loads a form, adds a bunch of data, then doesn't submit within the lifespan of the form's CSRF token (say 15 minutes), when they do submit (say after 20 mins) the request correctly fails due to an auth error.

I don't understand CSRF well enough to know how to handle the User Experience of this request error.

UX Options I can see are:

  1. Reload the page, which refreshes the CSRF token, but wipes the data unless I can cache it/stick it in the url (would be a bunch of work to implement across all our forms)
  2. Log user out when the token expires (pain for the user, but super safe for CSRF)
  3. If the CSRF token is rejected, I simply request another fresh CSRF token and resubmit the form... but I think this would defeat the purpose of the CSRF token!
  4. Add a countdown timer to the form, showing the user how much time they have to complete the form before the CSRF token expires
  5. ...?

I'd really value any thoughts on how you are handling the User Experience side of CSRF tokens, and/or reflections on the options I've considered above.

I believe this is a general question about CSRF, but in case it's relevant, here are the docs for the system I'm using:

0 Answers
Related