I think a lot of the responders have missed a very big point. JWT's that gives someone god like full access to every single API endpoint is bad. We know this. This is regardless of whether it is in a SPA or whatever else. But a significant number of tutorials specifically illustrate how to do this. In turn, every user has all access or no access.
Now come on, we are better than that, right?
Then, we decide to put these tokens in a place where anything has unrestricted access to the value. Sure, someone can get a hold of the cookie or do some magic to send requests as if they are you. But why even bother if I can just read the value from local storage. Hey thanks for the token. This god like power token is mine and I will use it for the... oops, you didn't set an expiration.
I guess you'll invalidate all of your user's tokens by changing your secret. Weeeeeelllllllllllll, hopefully you didn't follow the tuts and store your keys in such a way that you have to do a new deploy. Either way, now you just logged your users off in the middle of their purchase. Maybe they were customizing a product. Maybe they were finalizing a purchase. They click next and booooooommmmm!!!! They aren't logged in. I guess I'd go to amazon then.
If you were to practice being honest about security issue, you would tell me that you invalidated my login because another user's had their's compromised. I'd probably stop trusting you. Just stop for a second and say the words out loud. "I'm going to build a security layer that requires that I invalidate all users logins if a single user is compromised." Small app or big app, doesn't matter, that's just a terrible idea and should be reserved for catastrophic last resorts.
Now, if you have made it this far, you're thinking "Forget this guy, I know more than him because I'm a high IQ googler..." Well, here's a few others that just say no to doing stupid and careless things with people's secure data. Honestly, you all should be ashamed of yourselves. tsk, tsk.
auth0.com/docs/security/store-toke...
Browser local storage (or session storage) is not a secure place to store sensitive information. Any data stored there:
Can be accessed through JavaScript.
May be vulnerable to cross-site scripting.
If an attacker steals a token, they can gain access to and make requests to your API. Treat tokens like credit card numbers or passwords: don’t store them in local storage.
Also known as Offline Storage, Web Storage. Underlying storage mechanism may vary from one user
agent to the next. In other words, any authentication your application requires can be bypassed by a
user with local privileges to the machine on which the data is stored. Therefore, it's recommended
not to store any sensitive information in local storage.
Use the object sessionStorage instead of localStorage if persistent storage is not needed.
sessionStorage object is available only to that window/tab until the window is closed.
A single Cross Site Scripting can be used to steal all the data in these objects, so again it's
recommended not to store sensitive information in local storage.
A single Cross Site Scripting can be used to load malicious data into these objects too, so don't
consider objects in these to be trusted.
Pay extra attention to "localStorage.getItem" and "setItem" calls implemented in HTML5 page. It
helps in detecting when developers build solutions that put sensitive information in local storage,
which is a bad practice.
Do not store session identifiers in local storage as the data is always accesible by JavaScript. Cookies
can mitigate this risk using the httpOnly flag.
There is no way to restrict the visibility of an object to a specific path like with the attribute path of
HTTP Cookies, every object is shared within an origin and protected with the Same Origin Policy.
Avoid host multiple applications on the same origin, all of them would share the same localStorage
object, use different subdomains instead.
That's enough for now. Funny how OWASP recommends using cookies.....
As smokey the bear say's, "Only you can prevent people's secure data from being leaked by half reading documentation and trusting what that guy Steve said on StackOverflow." Ok, maybe Smokey didn't say that. But seriously, are you going to trust Steve? Come on, it's Steve.
(EDIT)
Just wanted to add a little more...
You wouldn't store passwords in local storage, right? If you just handed me a password, I'd still have to do at least some work to find out what user it went to. Think about it, just a password sitting out in the open can only do damage if I know the corresponding username. Does this hold true with tokens... No, Steve, it doesn't. A token by itself is enough, most of the time.
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.
I think a lot of the responders have missed a very big point. JWT's that gives someone god like full access to every single API endpoint is bad. We know this. This is regardless of whether it is in a SPA or whatever else. But a significant number of tutorials specifically illustrate how to do this. In turn, every user has all access or no access.
Now come on, we are better than that, right?
Then, we decide to put these tokens in a place where anything has unrestricted access to the value. Sure, someone can get a hold of the cookie or do some magic to send requests as if they are you. But why even bother if I can just read the value from local storage. Hey thanks for the token. This god like power token is mine and I will use it for the... oops, you didn't set an expiration.
I guess you'll invalidate all of your user's tokens by changing your secret. Weeeeeelllllllllllll, hopefully you didn't follow the tuts and store your keys in such a way that you have to do a new deploy. Either way, now you just logged your users off in the middle of their purchase. Maybe they were customizing a product. Maybe they were finalizing a purchase. They click next and booooooommmmm!!!! They aren't logged in. I guess I'd go to amazon then.
If you were to practice being honest about security issue, you would tell me that you invalidated my login because another user's had their's compromised. I'd probably stop trusting you. Just stop for a second and say the words out loud. "I'm going to build a security layer that requires that I invalidate all users logins if a single user is compromised." Small app or big app, doesn't matter, that's just a terrible idea and should be reserved for catastrophic last resorts.
Now, if you have made it this far, you're thinking "Forget this guy, I know more than him because I'm a high IQ googler..." Well, here's a few others that just say no to doing stupid and careless things with people's secure data. Honestly, you all should be ashamed of yourselves. tsk, tsk.
auth0.com/docs/security/store-toke...
Browser local storage (or session storage) is not a secure place to store sensitive information. Any data stored there:
cheatsheetseries.owasp.org/cheatsh...
Local Storage
That's enough for now. Funny how OWASP recommends using cookies.....
As smokey the bear say's, "Only you can prevent people's secure data from being leaked by half reading documentation and trusting what that guy Steve said on StackOverflow." Ok, maybe Smokey didn't say that. But seriously, are you going to trust Steve? Come on, it's Steve.
(EDIT)
Just wanted to add a little more...
You wouldn't store passwords in local storage, right? If you just handed me a password, I'd still have to do at least some work to find out what user it went to. Think about it, just a password sitting out in the open can only do damage if I know the corresponding username. Does this hold true with tokens... No, Steve, it doesn't. A token by itself is enough, most of the time.