Is it safe to use one CSRF token per form on my page, ex:

    <input type="hidden" name="token" vale="<?=$data['login_token'];?>" />"
    <input type="hidden" name="token" vale="<?=$data['register_token'];?>" />"

Or should I just use one generic token for every form, ex:

    <input type="hidden" name="token" vale="<?=$data['token'];?>" />"
    <input type="hidden" name="token" vale="<?=$data['token'];?>" />"

Note that I will refresh the token on each page request.

  • Why are you generating more than one form per page? – Robert Mennell May 9 '16 at 19:11
  • A third option: Use one per session, without chaning it on every page load. I don't see why that would be less secure, but there might be something I am missing. – Anders May 9 '16 at 19:34
  • Related: security.stackexchange.com/questions/26390/… – Anders May 9 '16 at 19:38
  • 2
    @RobertMennell should I not be? say I have the profile page for a user and have a change password field and a update status field. wouldn't I want one form to point to a page that deals with changing the password and another form to deal with updating statuses? Idk though I'm still learning this wonderful world of programming :) – MisterQuacker May 9 '16 at 19:43
  • 1
    Possible duplicate of Why refresh CSRF token per form request? – SilverlightFox May 10 '16 at 9:13

As this question mentions, a single random unguessable token per session is sufficient.

When you start generating tokens per-page or per-form, you're simply limiting the impact of a CSRF token being leaked. Singular token leakage cases are relatively rare bugs, but XSS is obviously a common vector.

In certain cases it does indeed make sense to have a per-page or per-form CSRF token, as when combined with other protection features (e.g. disabling Ajax with CSP's connect-src directive) you can limit an XSS bug's ability to compromise CSRF tokens to the page which the XSS occurred, assuming you ensure that the token can't be re-used elsewhere.

Some people promote per-page or per-form CSRF protection as a way to increase security when using a double-submit cookie method, but I don't think this is sensible: if you have a bug that lets you read a cookie, you'd just read the session ID.

The flipside of the argument is that by implementing the more granular CSRF protection, you add additional complexity to your code, and that increases the attack surface and potential for bugs.

Personally, I'd stick with a single token per session, then implement other anti-automation controls (e.g. captcha, password re-entry) on top of this when needed for additional security.

| improve this answer | |
  • Just want to add that per-page/form generally messes with the back button in complex ways. – Neil Smithline May 10 '16 at 2:42
  • Agreed. Per-request CSRF is bad for Back button and caching too – Neil McGuigan May 10 '16 at 2:48

Consider what you're protecting against: an attacker tricking a user into making a request they don't think they're making. How would multiple different tokens on the page protect against that any more than a single one?

| improve this answer | |
  • 3
    Limiting the impact of token leakage. – Polynomial May 9 '16 at 19:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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