I have a REST API which is running in one domain and I have a client in another domain. To prevent CSRF I have configured REST API to accept request originated from client application only. I have added proper encoding as per owasp XSS prevention cheat sheet to prevent any XSS attack on my application. Can I say that my REST API is safe from CSRF attack? Do I even need a synchronizer token to make my API safe?

As per my understanding of CSRF or XSS attack can lead to CSRF attack, as i am preventing both of them, is my application is vulnerable to CSRF?

2 Answers 2


To prevent CSRF the most effective method is to provide a CSRF token along with every request. This is a token that is generated on the server side and associated with a particular session. Then whenever that session submits a request, your server side code will check to confirm the correct CSRF token was submitted. If it was not, a CSRF attack has taken place and the request will be rejected.

Often times these tokens are stored in hidden fields, but if you are using a REST API then I suspect you are making a lot of AJAX calls and this probably isn't the best method. I would suggest creating a global javascript variable that is initialized with the CSRF token one time and then accessed whenever submitting a request. If you are using something like jQuery it is fairly easy to include another request parameter in all AJAX calls, so this might be an option as well. The latter is typically what I do, and it makes for much cleaner code.

Here is a link to OWASP's CSRF prevention cheat sheet. I would recommend giving it a read.

  • thank you for the response. I have implemented storing csrf token in javscript as you suggested. But my concern is if an attacker who has user's session, can make a call to /getToken service and then user the token in further rest services calls, in this scenario csrf token is not help me to prevent csrf attack. (Is this scenario exists? if yes how do they do it?)So what is the purpose to keep csrf token?
    – MShah
    Oct 22, 2013 at 5:58
  • 1
    @MShah If they already have the user's session then they can do what they like anyway. Oct 22, 2013 at 8:47
  • Silverlight is correct. All a CSRF attack does is execute a one way action on behalf of an authenticated user. They cannot read the response from this request, only execute the request. So they could potentially call /getToken, but they would not be able to read what the token is using CSRF.If a user has stolen a users session token then they can use the site as them and they don't need CSRF. Oct 22, 2013 at 14:41
  • @AbeMiessler thank you for your suggestions, So as per discussion I can go for /token GET REST service which will be called by my client application and token value i will store in a javascript variable. This token i will send in further secured REST API calls. One more question is, In owasp csrf guard 3.0 , tokenPerPage = true works with a form submission only, in case of ajax request it does not update token value once request is verified. Is there any way to get new token per request for ajax request?
    – MShah
    Oct 23, 2013 at 6:03

I presume you are authenticating requests using a session cookie?

Verifying the origin header is a valid CSRF defence, so you do not also need an anti-CSRF token. Browser support for the origin header is pretty good. But to be secure you must reject requests without an origin header - which will block non-supporting browsers.

There is a lot of confusion around CSRF and XSS. It is true that XSS attacks can bypass CSRF protection. However, this is somewhat misleading. XSS attacks can lead to all sorts of bad things, and bypassing CSRF is just one of these. You are absolutely right to protect against XSS attacks.

So your design is basically good. However, to answer whether your application is vulnerable you also need to confirm your implementation is good. If you have budget, hire a penetration testing company to check this.

  • 1
    No, the Origin header. If you're not familiar with it, it's worth a read tools.ietf.org/id/draft-abarth-origin-03.html
    – paj28
    Oct 21, 2013 at 15:55
  • Very interesting, thanks. I will look into this some more... However, I am not sure that this is what the OP meant.
    – AviD
    Oct 21, 2013 at 16:50
  • @paj28 thank you for your respoonse. Yes i am using httponly session cookie, which is jsessionid.
    – MShah
    Oct 22, 2013 at 6:01
  • @MShah - can you confirm how you are validating the request originated from the client application? Are you using the Origin header?
    – paj28
    Oct 22, 2013 at 9:26
  • @paj28 Its all ajax request for REST API, so it does add origin header and I have defined filter in REST API to allow only request originated from client application.
    – MShah
    Oct 22, 2013 at 11:37

You must log in to answer this question.

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