OWASP CSRF Prevention cheatsheet talks about two popular mitigations for CSRF - Origin/Referrer header check and Token based.

Are there any issues Origin/referrer check based mitigation that could have been caught by token based mitigation and vice versa? I am just trying to understand if we need to employ both of them in our applications. I would like to implement both of them if each of them has any drawback that could have been caught by the other one (If there is nothing as such - I would like to just select one of them for now and consider about adding other defense in depth measure at later point of time)

  • Just an opinion, but tokens seem to be pretty effective, while the Origin/Referer approach depends on browser implementations working as expected: which they don't often do. See MDN: Referer header and the browser compatibility notes for MDN: Origin header. – nbering Aug 10 '18 at 1:31

Token based approach is what I consider the most effective way of preventing CSRF attacks. If implemented correctly, token based measure never fails. While the other methods depend totally on the browser which isn't in one's control and shouldn't be relied upon. For example, EDGE still allows spoofing referrer header on GET requests. Also, privacy concerned users might disable sending such headers altogether. This may break your application for such users. These header based approaches are used specifically to reduce server overhead of storing and checking token for each user or for each page because you wouldn't have to store anything at all. I could see many drawbacks of using Origin/Referrer header while there aren't any for token based approach.

And, implementing one is enough to prevent CSRF attacks. There's no use in implementing both.


Your Answer

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

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