The interesting Stack Overflow question "Do cookies protect tokens against XSS attacks?" was closed as too broad, but as mentioned in a comment on it, there is a tangible question of "What happens if my anti-CSRF token is compromised by an XSS attack?"; it seems to me that answers to this question may provide information that will help people form opinions on the questions posed on Stack Overflow. Thus I'm posing said tangible question.

Let's assume that we're using the Double Submit Cookies method (unless there's a better method I'm unaware of) and we're storing JWTs (e.g., authentication tokens) in HttpOnly, Secure cookies.

The following Security Stack Exchange pages are relevant:


I've been reading more about anti-CSRF methods and came across this OWASP page comparing the Double Submit Cookies method to the alternative Synchronizer Design Pattern and the Encrypted Token Pattern, and stating that in terms of strength of defence they can be ordered as:

  1. Synchronizer (i.e.,CSRF) Tokens
  2. Double Cookie Defense
  3. Encrypted Token Pattern

(OWASP also states that 1. requires session state whereas 2. and 3. require no server-side state. There's a discussion on whether the Encrypted Token Pattern's actually stateless in the comments on the article entitled Leveraging the Encrypted Token Pattern. Said article also describes shortfalls of 1. and 2. that 3. solves, apparently without introducing new security concerns or architectural problems. As such, I don't know why OWASP listed it as third in terms of strength of defence. Perhaps due to the amount of testing that it's undergone at this point in time, since both it and Double Submit Cookies are relatively new; perhaps due to the discussion on statelessness/statefulness and replay attack protection in the article's comments? It'd be nice if there was an explanation of that ordering.)

Anyway... If anyone wants to respond to this question under the alternative assumption that either the Synchronizer Token Pattern or the Encrypted Token Pattern's being used instead, that would be neat.

  • 3
    that's like worrying about an enemy machine gunner having a pocket knife...
    – dandavis
    Commented Jan 11, 2018 at 9:23
  • @dandavis ' concise comment seems to agree with the one answer to the StackOverflow question ( stackoverflow.com/a/36980059/805141 ), as well as the first answer I received to this question ( security.stackexchange.com/a/177311/92720 ). Since the second answer I received ( security.stackexchange.com/a/177325/92720 ) expresses that the attacker can take certain actions only after compromising the CSRF token, the comment might be somewhat at odds with that answer. Regardless, use of HttpOnly auth cookies + anti-CSRF protection might provide hardening via defence in depth.
    – Daniel
    Commented Jan 15, 2018 at 0:29

3 Answers 3


If somebody has an XSS in your site, they can do anything they want on that origin -- submit any form, perform any operation, etc. Javascript can modify the DOM in arbitrary ways, submit forms, modify the user's view, etc.

Consequently, stealing the CSRF token is the least of your worries -- the XSS allows anything on the same origin that a CSRF would allow. The only time you might worry about this is if you share the same CSRF token across multiple origins (which would be a poor practice to begin with).

  • I've been doing a days long research about auth security. Started out with saving user token in LocalStorage, read that it was bad everywhere, now using double-cookie-submit, but if XSS is "game over" anyway, why no use LocalStorage for tokens, after all? (considering it's MUCH simpler)
    – zerohedge
    Commented Oct 12, 2019 at 21:50

With XSS, you have read and write access to the DOM - among other - of the attacked user. You could for example read out sensitive data or perform phishing attacks.

But if you couldn't read the anti-CSRF token (which you of course can) - and you can't read the session token -, you couldn't perform write actions to the server in the name of the attacked user. You could still perform read actions to the server, so you could get sensitive data that isn't already currently displayed to the user, but you couldn't perform actions that change things.

But when your anti-CSRF token is compromised, an attacker could perform any action that isn't further protected by challenge-response mechanisms (this is often the case when for example changing the password or email address, which commonly requires the entering of the current password).

So I disagree with people who would say that it is nothing to worry about. Compromising the anti-CSRF token enables an attacker to do much more damage, as it upgrades read-only access to the server to read-write access in the name of the attacked user; it's only insofar irrelevant as you can't prevent the compromise of the token once you have an XSS vulnerability.

  • 2
    "If your CSRF tpken is compromised...": If there is XSS, isn't it always compromised? I know of no way to secure it against XSS.
    – Anders
    Commented Jan 11, 2018 at 10:09
  • But lets assume I can't read it. I can still load whatever form I want in an hidden iframe, fill in whatever data I want, and hit submit, all using JS. So actually reading the CSRF token is not stricly necessary.
    – Anders
    Commented Jan 11, 2018 at 10:11
  • 1
    @Anders Yes, it's always compromised (I did point that out in my answer, twice). I took this as a theoretical, "what-if" type question. And here, compromise of the token is what enables write access to the server, which you otherwise wouldn't have. It's true that you don't technically have to read it, but I think in the context of this question that could be considered "compromised" as well.
    – tim
    Commented Jan 11, 2018 at 10:21
  • Sorry, first comment was a bit stupid... ha ha.
    – Anders
    Commented Jan 11, 2018 at 10:27
  • @Anders No, problem; my answer is probably not as clear as it should be. What I basically wanted to get across was CSRF=write access to server, XSS=read/write to client + read to server + CSRF (ie write to server).
    – tim
    Commented Jan 11, 2018 at 10:33

An XSS attack, while it is ongoing, strictly dominates CSRF; anything an attacker could do with CSRF, they can do with XSS (and much more besides).

However, there is a question: what happens after the XSS attack ends (e.g. because the victim closed their browser)? There are several possibilities.

  1. If the attacker stole the session/access token and refresh token then the attacker can continue to control the victim's session until the session is ended by the server (e.g. hits a hard lifetime limit or the server revokes the session/refresh token). This scenario doesn't require that the user's device ever go online, much less interact with the attacker, again. This is the worst-case scenario, and is why session/access/refresh tokens are often stored in HttpOnly cookies.
  2. If the attacker stole the CSRF token but not any other then the attacker can continue to make CSRF attacks against the victim (once they open their browser to an attacker-controlled page again, if they closed that; they don't need to have a tab open to the target site though), until such time as the attacker's session ends or their CSRF token changes. In effect, the attacker can bypass the site's CSRF protection for anybody who the attacker has hit with XSS until such time as the victim logs out, their session expires (without, or until, refreshing), or the CSRF token changes for any reason (e.g. maybe it changes every time the session refreshes). The attacker still needs to be in a position to carry out such a CSRF attack, though, and - assuming the CSRF tokens are per-session as they should be - the attacker will only be able to use this against however many users the attacker got XSS on.
  3. If the attacker did not steal the CSRF token or session/refresh token, or the tokens were invalidated (e.g. because the user logged out rather than just closing the tab) then the attacker can't do anything at all.

As you can see, there is a small amount of additional risk from XSS if the attacker retains an ability to do CSRF even after the XSS ends but doesn't retain access to the session. However, in practice, that's a really minor risk. It only becomes relevant if:

  • the session (or at least the validity overlap of the stolen CSRF token and some session) lasts after the victim ends the XSS,
  • the attacker needs access longer than the duration of their XSS to complete their attack,
  • the attacker can complete (or at least make meaningful progress on) their attack using only CSRF, without seeing the responses, and
  • the attacker remains in a position to carry out CSRF attacks (but not the XSS attack, which probably means the victim closed a tab to the vulnerable site but not to the malicious one).

As you can see, that's a pretty narrow set of constraints, and only apply to victims of the attacker's XSS (which is hopefully very few of your users). Furthermore, while the attacker may have gained information about the victim's account during the XSS and use that info to guide their CSRF attacks, the further damage that the attacker can do is nonetheless limited to CSRF, which is often less harmful than XSS.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .