Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

OWASP suggests that when implementing CSRF protection any attempt to go 'Back' in the browser will cause issues as Interaction with this previous page will result in a CSRF false positive security event at the server.

I've seen online banks handle this by destroying the session as soon as you hit back, but i'm wondering if there's any alternative ways around this? Ideally, i'd like to keep the session but just redirect the user to the front page (that they land on after logon) but i'm not sure if that's a safe way of doing things.

This is presumably a common issue in web applications, what options do I have?


share|improve this question
up vote 4 down vote accepted

It's perfectly possible to use the Synchroniser Token pattern together with proper navigational/multi-tab support. It's only if you take the questionable advice:

To further enhance the security of this proposed design, consider randomizing the CSRF token parameter name and or value for each request

that you have problems. In reality there is no good reason to do this on every request.

There is only a benefit to cycling the CSRF token at the point where a session elevates authorisation - typically on login and other paths that changes logged-in state (eg registration, account recovery, switch-user). These are the points at which you should also be cycling your session identifier, so it makes sense to do both at once. Changing the session ID prevents session hijacking through session fixation; changing the CSRF token prevents a CSRF attack through session fixation.

Navigation back to a cached page in the logged-out or previous-login state (or holding one open in another tab) and then trying to do something will indeed break, but most people probably won't be expecting that to work at that point.

You can put in some JavaScript to detect that situation if you like, checking that the session cookie matches the one that was used at page creation time. (Or an associated cookie that isn't the identifier and isn't httponly, as appropriate.) Then if it doesn't match you can add a warning div and reload link to the page, and/or prevent active form controls on the page from being responsive. You'd run that check onload, plus onpageview for bfcache if you're allowing caching, and potentially on an occasional poller to catch the multi-tab case. (This can also be of use to catch session timeout on the client side and present a friendlier error.)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.