For a REST-api it seems that it is sufficient to check the presence of a custom header to protect against CSRF attacks, e.g. client sends

"X-Requested-By: whatever"

and the server checks the presence of "X-Requested-By" and drops the request if the header isn't found. The value of the header is irrelevant. This is how Jersey 1.9's CsrfProtectionFilter works and it is described in this blog post: http://blog.alutam.com/2011/09/14/jersey-and-cross-site-request-forgery-csrf/. The blog post also links to NSA and Stanford papers stating that the custom header itself is sufficient protection:


  The first method involves setting custom headers for each REST request
  such as  X-XSRF-Header. The value of this header does not matter;
  simply the presence  should prevent CSRF attacks. If a request comes
  into a REST endpoint without the  custom header then the request
  should be dropped.   
  
  HTTP requests from a web browser performed via form, image, iframe,
  etc are  unable to set custom HTTP headers. The only way to create a
  HTTP request from a  browser with a custom HTTP header is to use a
  technology such as Javascript  XMLHttpRequest or Flash. These
  technologies can set custom HTTP headers, but  have security policies
  built in to prevent web sites from sending requests to each other 
  unless specifically allowed by policy. This means that a website
  www.bad.com cannot send a request to http://bank.example.com with the
  custom header X-XSRFHeader unless they use a technology such as a
  XMLHttpRequest. That technology  would prevent such a request from
  being made unless the bank.example.com domain  specifically allowed
  it. This then results in a REST endpoint that can only be called  via
  XMLHttpRequest (or similar technology).  
  
  It is important to note that this method also prevents any direct
  access from a web  browser to that REST endpoint. Web applications
  using this approach will need to  interface with their REST endpoints
  via XMLHttpRequest or similar technology.


Source: Guidelines for implementing REST

It seems however, that most other approaches suggest that you should generate a token and also validate this on the server. Is this over-engineering? When would a "presence of" approach be secure, and when is also token validation required?

Security is about defence in depth. Simply checking the value is sufficient at the moment, but future technologies and attacks may be leveraged to break your protection. Testing for the presence of a token achieves the absolute minimum defence necessary to deal with current attacks. Adding the random token improves the security against potential future attack vectors. Using a per-request token also helps limit the damage done by an XSS vulnerability, since the attacker needs a way to steal a new token for every request they make.

This is the same reasoning used in modern cryptographic algorithms, where n rounds are considered a minimum for safety, but 2n+1 rounds (for example) are chosen in the official implementation to ensure a decent security margin.

Further reading:


CSRF with JSON POST
Why refresh CSRF token per form request?

