Use of localStorage for JWT tokens insecure?

[danjac]

Reviewing the frontend code, I saw that it appears the Vuex store saves the JWT tokens in localStorage, against common security recommendations. Although this is just an example project, it's never a good idea to promote bad security practices that find their way into production applications, especially when teaching new developers the "right" way to build Single Page Applications. Would it be possible instead to re-architect this application to use e.g. HttpOnly cookies?

[btotharye]

so I'm kinda curious @danjac how would you do this then? Most articles and even code you look at use this same type of setup with vuex typically storing the token. I thought if you had enough form validation in your frontend a XSS attempt would be pretty low or no? I'm following this as I'm setting up a production level app atm sorta based off this and I'm kinda curious the impact of using the vuex store with proper form validation on any inputs.

[danjac]

For a browser frontend I would stick to server HttpOnly cookies that are not accessible to your JS code at all, combined with some form of CSRF protection for POST and other write requests. The index page that loads your application is rendered by your server, which includes a JSON script tag containing all the data you need to hydrate your Vuex store - for example the authenticated user.

I think the reason so many articles sidestep this issue is either just pure ignorance - every other article does it, so why not me? Assumption that Vue/React/etc will automatically handle XSS (they do to some extent, but can you ensure some obscure dependency from npm isn't doing something evil? And what if you want to render some user data as html, for example with some markdown editor?) and just plain convenience/laziness - it's easy to just throw a token into localStorage without further explanation of the tradeoffs that might confuse readers.

[F1r3Hydr4nt]

I found this: https://github.com/cthwaite/fastapi-jwt-cookies
And this: fastapi/fastapi#480

[ieferrari]

I think a better option is to save the token in a samtesite=Strict cookie

from owasp csrf-cheatsheet:

The Strict value will prevent the cookie from being sent by the browser to the target site in all cross-site browsing context, even when following a regular link.

afaik this will prevent csrf and xss attacks

[miurakazunori]

@danjac

Assumption that Vue/React/etc will automatically handle XSS (they do to some extent, but can you ensure some obscure dependency from npm isn't doing something evil?

HttpOnly is also ineffective if vulnerable to XSS attacks.
HttpOnly is effective against "cookie stealing" attacks, but hackers do not want to steal cookies.
If DOM manipulation is possible, other attacks (e.g., changing passwords) are still possible with XMLHttpRequest, because cookies are granted automatically.

[tiangolo]

Using Cookie-based authentication also has a lot of caveats and it would mean tightly coupling the authentication from the backend with browsers, etc. For now I would not want to do all that.

[lepture]

Cookie based authentication has HttpOnly flag, which can not be accessed by third party scripts or browser extensions. If you don’t want to increase the complexity, it is super easy to use signed cookie for the session. And it is much easier than the access token and refresh token mechanism.

[lepture]

Since this template is intended for browser-based use and has so many stars, it’s likely to be used by a large number of people. Storing access tokens in localStorage is unsafe, and widespread use of this template would expose many users to the same vulnerability. Given that this is a browser-focused template, I think it’s best to provide a secure implementation by default.