Consider CSRF protection with a fixed custom header

OWASP lists Custom Request Headers in their CSRF cheat sheet, which says "the client appends a custom header to requests that require CSRF protection" and "the API checks for the existence of this header". It can't be used with native <form>s but I think applications that can benefit from it are common enough.

The Spring Security documentation mentions that "there are known exploits in which headers can be set by another domain" when explaining "why the expected CSRF token is not stored in a cookie by default", but it seems that things has changed now. The OWASP cheat sheet doesn't say it is vulnerable, unlike "Naive Double Submit Cookie" which "remains vulnerable to certain attacks".

So it seems that simply checking for the existence of a custom header set by client-side script is safer than what is currently recommended for SPAs? If so it would be nice if Spring Security provide something like httpSecurity.csrf(csrf -> csrf.customHeader("X-YOURSITE-CSRF-PROTECTION")).

Start by comparing the OWASP CSRF cheat sheet with Spring Security's CSRF considerations and JavaScript SPA integration documentation cited in the issue. Determine whether checking a fixed custom header is safe and what configuration, documentation, and tests would be needed for a supported API; done means the security behavior and scope are decided.