Update: Cross-Site Request Forgery Prevention Cheat Sheet

[glasser]

What is missing or needs to be updated?

The CSRF sheet dictates that token-based mitigations are the correct way to solve CSRF issues, and describes custom request headers as a defense-in-depth mitigation.

However, the actual section on custom request headers makes it clear that it's very effective if you only care about "AJAX or API endpoints" and not <form> tags.

These days it's very common for web applications to do all of their server communication with JS rather than <form> tags. In this environment, custom request headers is a perfectly reasonable solution by itself (along with correct CORS configuration).

Developers building web API endpoints who are trying to avoid CSRF and don't care about supporting <form> tags should not feel like they are avoiding best practices by going with the simple custom request header approach and not implementing the much more complex token approaches.

Additionally, it's unclear how requiring custom request headers could really even be "defense in depth" — since it prevents the use of <form> tags, it does not actually combine well with the main token-based recommendations which are very focused on making <form> tags work.

How should this be resolved?

"Use of Custom Request Headers" should be moved from "Defense in Depth Techniques" to its own top level section.

The introduction should clearly state that token-based mitigations are necessarily to safely support <form> submissions, but that if your endpoint does not need to support <form> submissions then custom request headers are a good approach.

I'm not sure if custom request headers needs to be listed as also a defense-in-depth approach: requiring them breaks <form> submissions so I'm not sure when you could reasonably layer them on top of token based mitigation.

I'm happy to prepare a PR for this, if this approach is considered reasonable. On the other hand, if I'm entirely missing something here that would be great to learn!

[ikkisoft]

Using a custom authentication header as a mechanism to prevent CSRF represents a solid protection. Assuming no significant CORS misconfigurations, this solution is resilient and easy to implement. Personally, I don't see how this is a "Defense in Depth Techniques" since it's THE solution for several modern apps.

[mackowski]

@glasser that is true. We can move it from to its own top-level section. It will need a solid explanation (so list all constraints where it is enough to use only custom header to be secure). Do you want to make a PR for this change?