DEV Community

Discussion on: Using a Cookie-to-Header CSRF Token in Single Page Applications

Collapse
 
tiguchi profile image
Thomas Werner • Edited

I was just looking into the OWASP implementation recommendations for Use of Custom Request Headers and this is what they mention there:

This defense relies on the same-origin policy (SOP) restriction that only JavaScript can be used to add a custom header, and only within its origin. By default, browsers do not allow JavaScript to make cross origin requests with custom headers.

I'm not an expert but at a glance this looks to me as if all we need is the presence of that XSRF header to make it work. It just needs to be a custom header, and the value doesn't necessarily have to be a secret.

I guess making that header a random session-based secret could be an additional layer of security in case something's not right with the browser security, be it a bug or a changed setting, or a compromised browser. Maybe there's still a bunch of older browsers out there that don't enforce SOP. But these look like problems that are more on the user's side, where they unwillingly or willingly compromised their own security.

Overall it seems regenerating the token on every request is probably not necessary. I guess it would be enough to regenerate it once on sign in, or session refresh.

Another Google search reveals a similar discussion on Stackexchange.com.

Someone asks for clarification if the following is really true and sufficient security:

The value of the header is irrelevant. This is how Jersey 1.9's CsrfProtectionFilter works and it is described in this blog post: blog.alutam.com/2011/09/14/jersey-.... The blog post also links to NSA and Stanford papers stating that the custom header itself is sufficient protection...

The accepted answer confirms that a "token-less" CSRF header would be enough today, but generating and verifying a secret should protect against future changes

Collapse
 
hansenc profile image
Chris Hansen
Collapse
 
bytebodger profile image
Adam Nathaniel Davis

Much obliged. Those links are good reads. And they seem (to me) to confirm that, while the mere existence of the custom header may currently be "enough", it's probably not a bad idea to issue single-use tokens. Especially if that functionality has already been put in place.