Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Angular Double Submit Cookie patterns for CSRF suffers from sub-domain cookies overwrite? #34752

lijunhaoabroad opened this issue Jan 12, 2020 · 1 comment


Copy link

@lijunhaoabroad lijunhaoabroad commented Jan 12, 2020


Please read on how to disclose security related issues.
As the page said:
In a common anti-XSRF technique, the application server sends a randomly generated authentication token in a cookie. The client code reads the cookie and adds a custom request header with the token in all subsequent requests. The server compares the received cookie value to the request header value and rejects the request if the values are missing or don't match.

I assume angular only asks the server to compare the value of XSRF-Token cookie to the value of X-XSRF-TOKEN request header. This is the double submit cookie strategy , right ?

What happened if the attacked owns the sub-domain, and overwrites the XSRF-TOKEN cookie and forge the request? Why Angular didn't use Synchronizer Token Pattern to prevent CSRF attacks?



This comment has been minimized.

Copy link

@gkalpak gkalpak commented Jan 13, 2020

As explained here, the Synchronizer token pattern is a little more complex for the server (e.g. you will need to keep the token in the user's session info on the server in order to verify each request). It is more suitable for HTML-based applications that use forms to submit requests.

SPAs (which is what you usually build with Angular) do not typically rely on forms for submitting requests and there is no clear, generic way of setting up the Synchronizer token pattern. Of course, it is possible to implement it in our app (in a way specific to your app).

In contrast, the Cookie-to-header token technique that Angular uses by default (which is slightly different than the Double Submit Cookie technique) can be implemented in a way that is generic (i.e. fits most (all?) apps built with Angular) and can be easily utilized by JS (which does the heavy-lifting in SPAs). It is also simpler to implement the server part.

Finally, you can configure the cookies sent by the server to not be accessible on subdomains (if you don't control them). For more details, see this StackOverflow answer.

Closing the issue, since everything seems to work as expected, but feel free to continue the discussion below.

BTW, if you think you have identified an actual security vulnerability in Angular, please report it following the instructions here.

@gkalpak gkalpak closed this Jan 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can鈥檛 perform that action at this time.