Why can't you store important data in localStorage and, in general, is JWT somehow more dangerous than cookies?

Question

JSON Web Token

When using JWT, you need to store it somewhere (otherwise it is lost if the user refreshes the page). It would be convenient to store in localStorage/sessionStorage, but many tutorials and articles dissuade from this, they say, all JS scripts have access to localStorage, and if as a result of a vulnerability (a third-party script server is hacked, a vulnerability in its code, XSS) a cracker can steal the JWT, and use it (steal the session). But stealing httpOnly cookies in this way is impossible, and cookies have an advantage in this.

Sounds reasonable at first glance. But if you think about it, it doesn't work for me. Let's say we have an application, a "personal account", and, for example, there is a deleteDocument() function that deletes a document from the server via fetch / XHR to the backend (POST request with httpOnly cookie). And in this our application there is a vulnerability that allows you to execute JS code. It is impossible to steal a cookie through this vulnerability, but is it really not necessary? Anything a cracker might want to do, they can do directly in this code, such as calling deleteDocument(), and even though they won't get the cookie, they will cause damage.

Are there any situations where using an httpOnly session cookie protects us, but using localStorage and sessionStorage is vulnerable?

Examples of "excuses" from localstorage:
https://auth0.com/docs/tokens/token-storage#don-t-...
https://developer.okta.com/blog/2017/08/17/why-jwt...

Answer 1

Important data is usually never stored on the client, it is transferred, used and deleted.

Are there any situations where using an httpOnly session cookie protects us, but using localStorage and sessionStorage is vulnerable?

If there is a compromise of the client, then it does not protect in any way. The only place is where JS is generally not used at all, i.e. clients with disabled JS. Well, it's like walking down the street in knightly armor. Uncomfortable, but it seems to protect against the sword. Only they don’t go with a sword for a long time, more and more with machine guns.
Now about tokens. In theory, it is best to keep tokens not in localStorage, but in sessionStorage . This repository survives page reloads and does notshared between tabs. Those. when opening the same address in a new taba, a new session will be created. The storage is cleared when the browser and tab are closed. But it's terribly inconvenient to log in every time. Therefore, sound logic says to use localStorage, although if you are completely beaten off, you can store the token in a session cookie.
If you read those articles carefully, you can see that the benefits of session cookies are outweighed by the inconvenience of using them.
JWT Tokens are designed for microservice architecture. Those. you have some auth authority that issues you a token. This token is signed with relatively strong cryptography and is constantly rotated.
This token is passed to other microservices that can verify it through public keys (JWKS).
Those. if you want, you can build your services so that they trust not only your authentication center, but also google with amazon through OpenID. There are situations, for example, when you want to allow access to the service to employees of another company. For example, when such a company is huge (tens of thousands of employees). They are authenticated at home, and you check that the token is issued by the service of this company. It's not that hard to implement.
The implementation of authorization lies on the shoulders of each microservice and is directly tied to business logic. As a rule, this is some kind of internal microservice that is integrated with the middleware of the microservice.

Answer 2

If you connect malicious JS and the attack is targeted, then nothing will save. How do you not puff from this can not be protected. Unless you check the code of the libraries that you include on the site. This is actually not always possible. If you want to protect yourself, then do not connect scripts from third-party cdns. Download them, check for vulnerabilities at least superficially and look for oddities (working with cookies from js, etc.) and then install the script on the site.
With regards to protection against any crap like stealers, botnets and other things, then if you are sure that there are no vulnerabilities and you are not afraid of anything, then use localstorage.
If you do not need to check login on other domains, then the best solution would be httponly cookies and anticsrf tokens.
In all cases, tokens should be short-lived (preferably a few minutes).

Answer 3

Gyyy! localStorage, as I understand it, is INSIDE the browser itself. And I would like to know HOW you can look there! But cookies are transmitted over the network and they can be caught. You can also see localStorage, but it's difficult. If you break the page on which this browser breaks. But here the question is: -If the SERVER is BROKEN to get into the BROWSER?!?!?! In my opinion, this is bullshit with the demolition of localStorage. In addition, when using localStorage, you can DO NOT SEND cookies, and the server can throw a script that spins on the browser and the browser itself uses what it has for the server in localStorage, and sends ONLY the RESULTS of verification / use to the server. The browser can take the server data, do some chemistry with it, and then compare what happened with its localStorage. I do. What goes back is not what is in localStorage and not what I took from the server, and the result of processing data from the server and localStorage. And how can I see something from LocalStorage?!?!?! Cookies are even easier to intercept!

Answer 4

If you do it for yourself, then it is quite safe to use localStorage. Personally, I myself do not care where to store the authorization data. For example, in my last project, I shoved tokens into IndexedDB at all. Even if the user's browser is infected with a malicious extension, it is still necessary to guess the tokens in indexedDB to look for. In addition, even if you get a token, it will not work, since the token is by no means eternal.