There are a lot of blog posts from Stormpath that talk about how you ought to use cookies to store your JWT instead of sessionStorage/localStorage:

The main stated reason is that if a 3rd-party javascript dependency that you load is promised that it can pilfer through sessionStorage/localStorage and transmit off the JWT to somewhere.

But this is confusing as a reason to me. I understand the attack vector, but if you have a promised 3rd-party javascript dependency, aren't you effectively screwed anyway, since it can listen-in/capture anything your users do as they interact with your app?

There are a lot of blog posts from Stormpath that talk about how you ought to use cookies to store your JWT instead of sessionStorage/localStorage:

• https://stormpath./blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
• https://stormpath./blog/token-auth-spa
• https://stormpath./blog/build-secure-user-interfaces-using-jwts

The main stated reason is that if a 3rd-party javascript dependency that you load is promised that it can pilfer through sessionStorage/localStorage and transmit off the JWT to somewhere.

But this is confusing as a reason to me. I understand the attack vector, but if you have a promised 3rd-party javascript dependency, aren't you effectively screwed anyway, since it can listen-in/capture anything your users do as they interact with your app?

• javascript
• cookies
• single-page-application
• jwt

• 1 You can do whatever you want but you cannot steal the token. – zerkms Commented Jun 13, 2016 at 1:37

1 Answer 1

I'm the author of https://stormpath./blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

When XSS exist on a page, an attacker is privileged to:

• HTML5 web storage (local and session)
• Cookies that are not set with httpOnly flag
• Control of the tab until it is closed and the ability to make unauthorized requests

You can also start to formulate attacks to get around XSRF protection.

When an XSRF vulnerability exists, an attacker is privileged to:

• Making unauthorized requests from a 3rd party domain, if you can lure a user there (or send them there in the presence of XSS).

You can see that when an XSS vulnerability exists, you are able to make unauthorized requests and an attacker would need to jump through some more hoops to exploit XSRF. This means that when XSS exists (regardless of XSRF protection or not), the attack vector of making unauthorized requests will exist.

Hopefully, that clears things up for my next point.

An XSRF attacks or unauthorized requests has less impact and scope than stealing a stateless token that represents the user's identity and session. Leaking the token means that an attacker will have full control to formulate an attack on behalf of the user, on his time, on his machines.

In conclusion, in presence of XSS when you:

• store an access token in web storage, the tokens for any user that uses your site during the time of the existence of XSS is promised. This means an attacker could get thousands of valid access tokens and can possibly do a lot of harm (even more if you store refresh tokens in web storage). The users are also vulnerable to making unauthorized requests from their own browser.

• store an access token in a httpOnly cookie, the tokens for any user are not promised. But, the users are also vulnerable to making unauthorized requests from their own browser even in the presence of XSRF protection.

Hope this information helps.