17

This article from Auth0 recommend storing the JWT locally in a local storage (or cookie). But this article from OWASP recommend not to story any sensitive data locally (not even sessionStorage)

So, is it safe to store the JWT token locally or not?

  • Is this feedback from a pentest? I asked basically the same question a couple of months ago ^ – JMK Feb 9 '18 at 22:30
22

How bizarre! I asked basically the same question about a month ago.

In the end, we decided that using localstorage for the JWT token was ok, as long as we also did the following on the HTTP level:

  • Ensure the entire site was served over HTTPS
  • Ensure the use of HSTS
  • Ensure that, once live, only the actual redirect URL was included in the Auth0 rules, as well as our source code
    • We use the Angular CLI. It turns out that, despite the tree shaking provided by WebPack, unused variables still show up in the compiled source code, for example localhost:4200
    • Make sure that there are no localhost URl's actually on Auth0 (on the allowed redirect page, for your client). Make a seperate Auth0 account for testing
  • Add the X-Frame-Options header to every HTTP response, and set it to Deny
  • Set X-XSS-Protection to 1
  • Set X-Content-Type-Options to nosniff
  • Make sure Content-Security-Policy is restricted to your own domain name, and any CDN's you may be pulling scripts in from
  • Set Referrer-Policy to same-origin
  • Limit the JWT expiry on Auth0 to 1 hour

The above will give you an A/A+ on securityheaders.io, and will prevent the most common attacks (somebody embedding your website in an iframe, and extracting data from localstorage, for example).

| improve this answer | |
  • 2
    If we use localStorage even with all the things you mentioned, won't the Chrome Extension/Firefox Addons be still able to fish the token out from the localStorage? – Pavan Nov 26 '18 at 7:21
  • 3
    @Pavan, yes you will be able to fish it from there, see here. But you are also able to read httponly cookies from chrome extension resource here. – eddyP23 May 2 '19 at 12:13
5

Well it depends. If you have an XSS vulnerability within your application an attacker can extract and use the JWT from your local storage.

A method I've used and I think Auth0 indicate is to use the cookie as the JWT storage and use the flags HTTP Only and Secure this way if you have an XSS vulnerability the cookie cannot be read and is only transported in a secure manner. CSRF is less of a risk these days as all the modern frameworks include CSRF mitigation.

This would mean validation extracts the JWT from the cookie on the server side to validate. My personal view is to use a cookie as storage as CSRF is easier to find and mitigate when compared to XSS attacks which have a large attack surface.

| improve this answer | |
  • 3
    If you are using a cookie for storage, is there any real benefit to using JWT? – Julian Knight Feb 9 '18 at 22:42
  • Yes - all the benefits of using a JWT. Signed tokens, expiry periods, passing it on to other systems that have to validate claims. – McMatty Feb 9 '18 at 22:59
  • 5
    Sorry, I'm not trying to be difficult, I really want to understand this. I get the claims part though that is a relatively limited use case. Expiry and signing can be easily done with session cookies too can't they? As far as I can see, if you are going to use cookies, there is only a single use-case for JWT - claims passing? – Julian Knight Feb 10 '18 at 20:47

Not the answer you're looking for? Browse other questions tagged or ask your own question.