I have heard that CSRF prevention techniques are not natural for Web APIs.

For instance, we might have a client application at domainA that implements both the Synchronization Token Pattern and the Cookie-to-Header pattern. When the client POSTs to the resource server at domainB, the resource server needs to validate those security values, and since the resource server would not know what synchronization token value nor what cookie-to-header value to expect, it will have a hard time validating those.

That being said, the resource server could validate the synchronization token and/or the cookie-to-header value using the same technique that it uses to validate the access token. Given that, why are those two techniques considered inappropriate for a Web API?

  • 1
    The question in the final paragraph does not reflect that in the title. Could you edit? – billc.cn Sep 29 '16 at 18:26
  • @billc.cn Done. – Shaun Luttin Sep 29 '16 at 18:32
  • 1
    Generally (though not necessarily), these techniques require server state. Most APIs are now based on REST principles, one of which is that the server should be stateless. I suspect that is the objection. – crovers Sep 29 '16 at 18:52
  • @crovers Doesn't the validation of an access token also rely on server state? And if it doesn't, then why do the CSRF techniques need to rely on server state? – Shaun Luttin Sep 29 '16 at 18:54
  • @ShaunLuttin Access tokens MAY require server state - and if they do, they are a place where people are willing to bend a bit (or direct to a separate server that does hold state). If there are shared secrets between all servers, though, you can do CSRF tokens that don't require state - I don't see an objection to those. – crovers Sep 29 '16 at 20:09

In a Web CSRF flow, the server sends the token as part of the response that serves the webpage, so the token is delivered "for free". Typically, the same server is also the target for those POST requests so it can easily validate the tokens.

When you call a Web API, the target is probably a different server so the token will either have to be communicated out-of-band or the client will have to send a request just for the token to use in a subsequent request. In either cases, the Web API server handles double the number of requests, which is wasteful.

Good alternatives are digital signature schemes or HTTP methods/headers not allowed by browsers.

  • This makes sense. What it leaves out, though, is why the delivery/validation of a CSRF token is not appropriate whereas the delivery/validation of an access token is appropriate. – Shaun Luttin Sep 29 '16 at 18:59
  • Could you clarify what do you mean by "access token"? Are these OAuth tokens? – billc.cn Sep 29 '16 at 19:18
  • Yes. These are OAuth tokens. – Shaun Luttin Sep 29 '16 at 19:25
  • In the case of OAuth tokens, they are designed to be requested once and reused for many resource requests. You also normally get them from yet another server so no way to save that request. They can replace CSRF tokens in some cases. – billc.cn Sep 29 '16 at 19:25
  • Yes. I understand that too. What I am trying to get at, is why are access tokens a viable replacement for CSRF tokens. It seems like the problems with CSRF tokens should also be problems with access tokens. You might have answered this in your last comment, when you mentioned that access tokens are for many requests... are CSRF tokens per request? That would indeed lead to a lot more overhead! – Shaun Luttin Sep 29 '16 at 19:27

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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