The CSRF Cheat Sheet by OWASP, concerning (Anti-)CSRF-tokens is quite confusing. For a State(ful)-scenario (the Synchronizer Token Pattern), they write:

... for AJAX calls it is recommended to add in parameter than in header. If you need to add it to header, it is better to make sure that the token header is not being logged at your server.

In the next paragraph, they write:

Inserting the CSRF token in the HTTP request header via JavaScript is considered more secure than adding the token in the hidden field form parameter. In this situation, even if the CSRF token is weak, predictable or leaked but still an attacker cannot forge the POST request directly by setting the custom request header through XMLHttpRequest.

Based on an answer to another question on StackExchange, I came to the conclusion that sending it as a header has one disadvantage: different frameworks expect the token in different headers (X-Requested-By, X-Requested-With, X-XSRF-TOKEN, X-CSRF-TOKEN). However, I still cannot understand which is more secure? The token as a parameter-value or as a header (for Ajax-calls)? And why?

  • Can I understand your question as "Why does OWASP argue for headers in one case and against headers in another case?" – MechMK1 Jun 5 at 15:30
  • 1) Yes en 2) which one is more secure? – LowLevel Jun 5 at 17:34

Your Answer

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

Browse other questions tagged or ask your own question.