Is it safe to include a CSRF token for a REST service as a Http Response Header?

Question

I have a set of REST services that are protected by CSRF using something similar to OWASP's Synchronizer Token Pattern (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet). * REST is implemented using Java and JAX-RS * Security is implemented using Spring Security CSRF tokens * HTTP PUT, POST, and DELETE are protected

At my Web-App startup, I write the correct CSRF token in the HTML page and then the application includes the token as "X-CSRF-HEADER" in the Request Headers for every single request.

I also have clients that access the URLs directly (curl command-line and others for example).

The alternate clients need to get the CSRF token somehow (after authenticating of course).

Is it safe to include the token as an HTTP Response Header for GET requests? If so, then I could include it in the Response Header and a client could read it out and include it in future Request Headers.

Is that safe?

Answer 1

It is generally considered safe to include the CSRF token in the response headers. Just as the body of a request, response headers are encrypted in SSL responses and not accessible across domains. The reason the CSRF token is not rendered to the response by default was to ensure we delay creating a session until it is necessary. For details, see SEC-2276