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

Without going into too much details I have a site which is 100% Ajax. All requests to the site (both GET and POST) are done via Ajax. Now I have to implement CSRF protection, and all the solutions I came across boil down to sending a CSRF token in the headers, but most of them get this token from either HTML or a cookie that came with the GET request.

Now as my site is 100% Ajax and it doesn't reload. I wonder if I could, before each POST request, make a GET request to the server to get token and then submit it in the headers along with the POST request, for example

Submit GET request to to get the token and then submit that token along with the request in the headers, if someone from another site makes a GET request to and the server returns a token, then as far as I know they are still not able to read that value.

As the token is generated on a per session basis, I can simply check that the submitted token is the same token I have in the memchache which is associated with that session.

Could someone tell me if this would work?

share|improve this question
First, you are paying RTT twice for every request, which is a big performance cost (…). Also, are you keeping an array of tokens in session? If not how would you handle multiple (obviously async) requests? – Mike S Jan 9 '13 at 19:04
up vote 4 down vote accepted

Yes, you could do this. This should be fine. It is a reasonable defense against CSRF.

Do make sure that side-effecting actions can only happen via POSTs (never via GET), and that all POSTs check for the presence of the token. Also, make sure you generate the token as a cryptographically-strong pseudorandom number (e.g., using CryptGenRandom(), /dev/urandom, SecureRandom, or similar) and store it in session state.

I don't know if this has any benefit over, say, cookie double-submission -- but you could do it, and it should protect against CSRF successfully.

share|improve this answer
It just seams a lot easier to implement, Thanks for response :) – Dave Sep 16 '12 at 3:48

Really, two requests for each task is a performance overhead. You can simply achieve this using single request. You can simply validate the token during POST request, and send back the new token with each request. Using JS make sure you pick up the latest cookie value and attach it to every request AJAX sent.

In fact if you want to cut off your pain in CSRF protection of your web application, you can see OWASP CSRF Protector Project, (available for php only currently), it does everything required, to mitigate CSRF and works well with AJAX (both XHR and activeXObject)

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.