In a lot of different products the CSRF token is stored in a session.

Which means that if the session has expired then the next form submit will fail.

Example scenario: you open a login form, the session is implicitly created if you didn't have one yet and a CSRF token is persisted in a session and is put as a hidden field of a form.

Then you wait until the session is expired (and garbage collected), then you fill your credentials and submit it.

Now even if the credentials are correct you will see the ugly "CSRF token is invalid" (or something similar) form validation error message.

So the question is: is there a secure way to improve this flow?

PS: ... apart of using AJAX to periodically poll some endpoint to keep the session alive.

  • Just force a relogin by reloading the page to create a new session and CSRF token May 10, 2015 at 23:42
  • I would still display some sort of message. The mental model of nothing being wrong with authentications failing for no apparent reason contributes to the efficiency of some auth spoofing attacks. May 11, 2015 at 0:00

2 Answers 2


(this question might be better suited for the User Experience site)

Change the error message to "We need you to log in again because you were inactive for more than XX minutes." Problem solved.

Let the user know how long they have exactly, because if they have to submit a complex form they need to be aware that they will need to collect whatever information they need and prepare whatever text they must input within a set time. Even better, monitor on which forms sessions tend to reset and use that information to figure out if you must support longer-lasting sessions.

Sometimes users might make a token expire before they even logged in as you pointed out. In that case, a formulation that is generic enough to cover both use cases will remove the need for you to try and test how the session looked like before it expired. You still need to address the confusion that such a message can cause for users who were not logged in before (their mental model might not accommodate the idea that individual forms expire rather than actual sessions).

You can do so by adding a "learn more" or "more details" link on your error message. Clicking that link can then display an additional paragraph that explains (succintly, and in very simple prose!) that Web login forms expire after XX minutes for security reasons, and the user was inactive for too long. You'll still need to ensure that additional text is visible to users without JS.

At this point you might as well implement your idea of serving a fresh CSRF token via AJAX when the user has been inactive for long enough...

Edit: some services directly display a timer indicating for how long the current page will be valid. You could go as far as implement such a timer on a standalone login page. This will at least prepare users to the idea that the page has expired / will expire, and can be especially useful if the page must be entirely refreshed when the timer expires. This being said, thee proper approach remains to never invalidate the existing login page.

XScreensaver login UI with a timer

  • "Your session has expired because you were inactive for more than XX minutes" --- the thing is that the user hasn't been logged in yet. It's odd to say that to an anonymous user.
    – zerkms
    May 10, 2015 at 23:55
  • 1
    Are you able to detect that specific case in Web frameworks? This is really a marginal case, so you could use a more generic formulation "We need you to log in again because you were inactive for too long", and possibly a "learn more" link on your error message where you can explain (in very simple prose!) that sessions expire for security measures and the user was inactive for XX minutes before logging in / since they last logged out. May 10, 2015 at 23:58
  • 1
    "We need you to log in again because you were inactive for too long" --- you're on the login page already. You cannot "log in again" since you was not yet :-)
    – zerkms
    May 11, 2015 at 1:03
  • 1
    Well that depends whether you have a login form on each page or a dedicated login page! :-) If you want exact advice for your site, then we need to have a 15 minute chat about your user base, your use contexts, and your site's UI... But I hope you get the general idea of what to do from the above :-) May 11, 2015 at 1:05

There's always been a trade between UI and security. To my knowledge, CSRF Tokens at login page is to protect against brute-force attack, which might also be achieved by other means like Captcha verification. It may also be abused, if possible, to make victims login to attacker's account and do some nasty stuff, but that's rare, I guess.

The best, I think, is to refresh the token with new one automatically as soon as it gets expired. Implementing plain CSRF Token that remains static throughout a period of time is of no use at all.

  • Please, enough with the "security-usability" trade-off myth. The people who say that are the people who don't understand the concept of a design space. Besides CSRF have to do with XSS attacks and not brute-force. Finally the harm caused by marginal and uncommon CSRF token expirations will never be anywhere near the harm caused by having legitimate users fill CAPTCHAs. In general, if you feel the need to say things such as "I think", or "I believe" in your answer, it's best to take some time and learn more before you provide answers. Usability engineering is not a matter of opinion. May 11, 2015 at 0:01
  • OK! Thanks for the clarification, but I don't understand CSRF tokens being used to protect XSS. It would be nice if could provide me with references I can learn these from. May 11, 2015 at 0:26
  • Blargh, I'm mixing myself up too! My bad. CSRF tokens have to do with CSRF, and indeed do not help with XSS (they in fact can be defeated by XSS). I don't get what you meant by brute-force either though. May 11, 2015 at 0:28
  • Using random tokens at login page requires attackers to obtain the token accordingly, making it hard to automate the brute-force attack. Otherwise, I don't see the use of CSRF tokens in un-authenticated areas, and being able to logged into a victim's machine merely does any harm. May 11, 2015 at 0:34
  • That just doubles the amount of requests, but the time-complexity of a brute-force attack would remain unchanged. CSRF is a type of attack where I can cause users to submit a form on a third-party website (e.g. by creating a link to yourbank.com/sendmoney?to=me&amount=alot). The existence of a CSRF token forces me to first render that form to obtain the token. I won't be able to do so as your existing user session would not be available to me -- I'd need to have stolen your credentials already. See owasp.org/index.php/… May 11, 2015 at 0:39

You must log in to answer this question.

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