I have a very long web form that could take hours for people to complete. The problem with this is when people take too long the CSRF token expires before they're done and when they hit submit they get a 403 error.

To fix this issue I'm thinking of doing an AJAX request every hour to update the session and extend the token expiry. Are there any security concerns with doing this? Or are there any better ways of handling this situation?

4 Answers 4


There are absolutely security concerns with this; otherwise, the session timeout would be useless in the first place.

That said, there may be good reasons to disable session timeouts, but in this case, you can and should do so explicitly, and with full regard of all consequences.

To add to the solution: while I think it's already questionable to have a single form on a single web page that takes that long to fill out without saving in the meantime, with the risk of loosing the whole work when anything goes wrong (big usability issue), I think what you do want to achieve is prolonging the session (and thus the validity of the csrf token) by doing an ajax request every so often when the user is still active. So you should monitor if any form fields where changed (for example, within the last 5 minutes), and only then start the ajax request.

  • With a bit of re-wording, this is a fine answer on its own.
    – Xander
    Apr 4, 2016 at 16:04
  • You are correct. I had missed in the question that the session would be extended as well. I added a note about that in my answer.
    – Anonymous
    Sep 29, 2016 at 12:22

You don't need to set an independent expiry time for the CSRF token, the token needs to be unique and valid for the current user session, when the user session will expire the csrf token expires along with the session, and then you must generate a new token. This could be a simple solution.

  • So you're saying just extend the session?
    – jwerre
    Jul 1, 2015 at 12:21
  • I could just ping the server on input change. That would extend the session and solve the problem.
    – jwerre
    Jul 1, 2015 at 12:22
  • 1
    It's a horrible solution in my opinion :)
    – eurialo
    Jul 1, 2015 at 12:23
  • ok so what is your solution?
    – jwerre
    Jul 1, 2015 at 12:24
  • 1
    @jwerre if https is used on the site then there is no way for a malicious party to capture the CSRF token of a user. There should be no reason to expire the CSRF token until the session expires. "In general, developers need only generate this token once for the current session. After initial generation of this token, the value is stored in the session and is utilized for each subsequent request until the session expires" from owasp.org/index.php/…
    – d0nut
    Apr 4, 2016 at 13:51

The solution that worked for me when user leaves the form for awhile with CSRF enabled for every request is to make a GET request in AJAX Success when request fails because token has expired. Then have a hidden field that continue to be updated with latest token and if at the time of making request it has expired you make a GET REQUEST to fetch latest TOKEN and then evoke click event on function that submits form which means the function has to be passed "this" or ID as part parameter.This makes the user not to realize the process of renewing token in the background


See the answer by Nicolai Ehemann for a more general answer. This answer assumes that the token is being refreshed without also lengthening the session.

I see no problem with this. It is effectively the same as resetting the token when the user reloads the page. Assuming that you are using https and properly implement the ajax request and token generation, an attacker should still not know what the user token is.

The same risks apply as do when normally generating a CSRF token without ajax, because to the browser, it is basically doing the same job.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .