Update: Cross-Site Request Forgery Prevention Cheat Sheet

[glasser]

What is missing or needs to be updated?

Cross-Site Request Forgery attacks occur because untrusted browser code can cause requests to be sent to a vulnerable server that are "special" in a way that the attacker could not send from their own machines. Typically this "special"-ness is that they contain cookies from a targeted user's browser. Less commonly, this could mean they contain basic auth credentials or that the server makes authorization assumptions based on the client's network (eg, explicitly looking at the client's IP address to make decisions, or by putting the server on a private network and assuming that any client talking to this server is authorized).

The mitigations discussed in the cheat sheet all assume that these "special" request qualities must exist in your system. However, an entirely different approach to solving CSRF is to avoid giving special treatment based on cookies, basic auth, and network properties. This approach may be appropriate for web servers that are primarily serving "API-style" traffic and which websites only communicate with via AJAX-style calls.

For example, a server that makes authentication decisions only based on a custom HTTP header (perhaps set from a value stored in browser localStorage) or a value in the body of a POST and not on cookies or network should be considered successfully defended against CSRF. Developers who have built servers with this property should not feel like they need to also set up token-based mitigation or (if #1010 is accepted) header-based mitigation.

How should this be resolved?

A new top-level section should be added describing "don't care about cookies/etc" as an appropriate mitigation technique, with the drawback that it is not helpful if you need your endpoint to be accessible via HTML <form>s.