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

Ours is a Ajax heavy application with concurrent Ajax requests. Generating unique tokens with each request or expire and creation of new tokens after a certain interval could get tricky with multiple concurrent Ajax requests.

My question comes from the suggested approach here -

Really, generating one each time the whole page is loaded should be enough if you are doing this over HTTPS, which you should be.

If we enable HTTPS, generating one CSRF token per session and using that token for all the requests in the session is enough?

share|improve this question
It may be worth generating a new token at any successful login step, but IMO changing on every request gets you nothing. Background: – bobince Jan 7 '13 at 14:50
up vote 7 down vote accepted

To prevent CSRF you need to have something unguessable in the explicit part of the request (GET or POST). Putting it into the POST part is preferred, since it's harder to leak it, and you typically only protect requests that trigger an action, which should be POST.

A per-session random value is unguessable and should do the job. The standard anti CSRF token mechanism built into works just like that.

HTTPS prevents leaking the token on the wire, and also prevents replay attacks. So a one-time-token doesn't seem necessary.

share|improve this answer
I was wrong, deleted my answer ^^ – Lucas Kauffman Jan 3 '13 at 8:32

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.