Storing a JWT in local storage is fine -- the point of this article is to explain to the 99% of developers who do this without thinking about it why it is bad and not recommended by OWASP and security people.
Obviously, if you are aware of the risks and choose to do so anyway, that's fine.
The tradeoff of using a JWT really comes down to this: speed vs security. JWTs are basically opting for speed (and a very minimal amount of speed, I might add) over security.
JWTs were not designed to be used for authentication or authorization data. They were designed to be used as one-time, short-expiration tokens to pass signed data from A->B. Using them as a way to "securely" store session data is abusing them in ways that are directly contrary to a secure mindset.
I guess if I could summarize my thoughts about your comment, I'd say this:
IMO, using session cookies is not only faster/more secure, but far simpler and safer for 99% of developers to use. If you're in the 1% who knows what you're doing and is willing to make the tradeoff, go for it. But for 99% of people out there, it's a bad idea.
Maybe it wasn't the intention but I feel that this article is contributing to hysteria around JWTs/localStorage.
I do software consulting related to an open source project I created and now I feel that I keep having to explain to my clients/companies over and over again why using a cookie would not make things more secure in their case.
I've even been asked to re-implement a perfectly secure authentication system because a security firm that my client was using recommended that they should stop storing their JWTs inside localStorage and that they should store it in the app memory as a global variable instead (as if that was any safer from XSS) - Also the JWTs had a 10 minute expiry so quite safe.
The problem is now that a lot of security consultancies are full of people who like to use articles like this to make blanket decisions on behalf of their clients in order to save them the ordeal of actually having to think about each company's case on an individual basis.
I just want to jump in real quick as one of those people who like to use articles like this to make blanket decisions. A few points as why security people say not to store session data in JWT and LocalStorage. Out of the box yes LocalStorage is more secure than a cookie for session data, however with the optional flag SameSite cookies are now equal to LocalStorage with built-in anti CSRF protections from the browser. Adding the HTTPOnly flag bring cookies to a higher level than LocalStorage. This is because now client-side JavaScript cannot access the cookies. The last part is where the recommendation to use cookies over LocalStorage is made in relation to potential exposure from XSS. Outside of XSS or vulnerabilities in the browser itself both are limited to exposure from physical access on the client-side in a general risk perspective.
The biggest risk for both options from a security perspective is XSS and while some may be confident in their ability to not introduce XSS, I can say that even the most experienced developers can have a hard time preventing XSS. I won't dive into too specific details but a shockingly common bypass to a lot of anti-XSS solutions is to switch the method from GET to POST or POST to GET in a request. Some popular frameworks even allow submitting GET parameters in the body which is completely wrong from the RFC point of view. The pervasiveness of XSS is why security people make the recommendation, we like to think in layers so if XSS is somehow introduced into the application you still have the layer from HTTPOnly on the cookie verse no additional layer on the LocalStorage side.
TLDR: LocalStorage out of the box is less insecure, but cookies offer more security than LocalStorage when done right. Security people aren't blindly making the recommendation there is a reason.
I would argue that using an httpOnly cookie doesn't add any security. At best you could say that it might make it slightly less convenient for an attacker to carry out the XSS attack.
Concur. There's no threat modeling that I could think of that would hold up httpOnly as being a significant factor if the threat vector up to that point has already leveraged XSS - so your local JS context is already 0wned - at this point, the exploit code just needs to directly execute from the compromised browser instead of sending the auth token to a remote server to be exploited from there. Considering the local context is already compromised, that hardly seems more than an inconvenience to the attacker, as jondubois indicated.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey! Thanks for the comment.
Storing a JWT in local storage is fine -- the point of this article is to explain to the 99% of developers who do this without thinking about it why it is bad and not recommended by OWASP and security people.
Obviously, if you are aware of the risks and choose to do so anyway, that's fine.
The tradeoff of using a JWT really comes down to this: speed vs security. JWTs are basically opting for speed (and a very minimal amount of speed, I might add) over security.
JWTs were not designed to be used for authentication or authorization data. They were designed to be used as one-time, short-expiration tokens to pass signed data from A->B. Using them as a way to "securely" store session data is abusing them in ways that are directly contrary to a secure mindset.
I guess if I could summarize my thoughts about your comment, I'd say this:
IMO, using session cookies is not only faster/more secure, but far simpler and safer for 99% of developers to use. If you're in the 1% who knows what you're doing and is willing to make the tradeoff, go for it. But for 99% of people out there, it's a bad idea.
Maybe it wasn't the intention but I feel that this article is contributing to hysteria around JWTs/localStorage.
I do software consulting related to an open source project I created and now I feel that I keep having to explain to my clients/companies over and over again why using a cookie would not make things more secure in their case.
I've even been asked to re-implement a perfectly secure authentication system because a security firm that my client was using recommended that they should stop storing their JWTs inside localStorage and that they should store it in the app memory as a global variable instead (as if that was any safer from XSS) - Also the JWTs had a 10 minute expiry so quite safe.
The problem is now that a lot of security consultancies are full of people who like to use articles like this to make blanket decisions on behalf of their clients in order to save them the ordeal of actually having to think about each company's case on an individual basis.
I just want to jump in real quick as one of those people who like to use articles like this to make blanket decisions. A few points as why security people say not to store session data in JWT and LocalStorage. Out of the box yes LocalStorage is more secure than a cookie for session data, however with the optional flag SameSite cookies are now equal to LocalStorage with built-in anti CSRF protections from the browser. Adding the HTTPOnly flag bring cookies to a higher level than LocalStorage. This is because now client-side JavaScript cannot access the cookies. The last part is where the recommendation to use cookies over LocalStorage is made in relation to potential exposure from XSS. Outside of XSS or vulnerabilities in the browser itself both are limited to exposure from physical access on the client-side in a general risk perspective.
The biggest risk for both options from a security perspective is XSS and while some may be confident in their ability to not introduce XSS, I can say that even the most experienced developers can have a hard time preventing XSS. I won't dive into too specific details but a shockingly common bypass to a lot of anti-XSS solutions is to switch the method from GET to POST or POST to GET in a request. Some popular frameworks even allow submitting GET parameters in the body which is completely wrong from the RFC point of view. The pervasiveness of XSS is why security people make the recommendation, we like to think in layers so if XSS is somehow introduced into the application you still have the layer from HTTPOnly on the cookie verse no additional layer on the LocalStorage side.
TLDR: LocalStorage out of the box is less insecure, but cookies offer more security than LocalStorage when done right. Security people aren't blindly making the recommendation there is a reason.
I would argue that using an httpOnly cookie doesn't add any security. At best you could say that it might make it slightly less convenient for an attacker to carry out the XSS attack.
I wrote a more detailed technical explanation here: dev.to/jondubois/comment/373l
Concur. There's no threat modeling that I could think of that would hold up httpOnly as being a significant factor if the threat vector up to that point has already leveraged XSS - so your local JS context is already 0wned - at this point, the exploit code just needs to directly execute from the compromised browser instead of sending the auth token to a remote server to be exploited from there. Considering the local context is already compromised, that hardly seems more than an inconvenience to the attacker, as jondubois indicated.