Why LocalStorage is Vulnerable to XSS (and cookies are too) 

A users login session can be stolen in so many ways. The best think you can do is accept the fact that your vulnerable to XSS attacks. And think about ways to mitigate the damage that can be done when your users session has been hijacked. One example banks use is to ask for some kind of 2FA step each time you make a money transaction. The attacker might have the login session but probably not the 2FA code.

Jeah XSS attacks are always possible and the solution is to do enough input validation both on the client-side and on the server

Completely agree with this, if you've got an XSS vuln then you've already lost the battle regardless of where you're storing things.

Awesome explanation and demonstration. Thank you!

ty sir, nother great explanation. cool demo

Some sites have dedicated pages with zero JS where you make a payment or enter sensitive info like a CC number (often on a subdomain). Can't use JWT, but cookies will still work. Just my 2¢

these are the vids we need

Correct me if I'm wrong, as I mostly had an experience as a backend dev, but I believe that xss attack and problem with local storage is quite different then what you describe. Practically if we have any vulnerability that allows for execution of malicious JavaScript on our side we practically screwed and yes, we can't do anything about it if attacker knows our auth flow. But problem with local storage as I understand it lies in that it's actually accessible to all JavaScript code without any domain protection, so if user goes to a site that attacker set up for him, then code on that site can read anything from local storage. Also even if you have authentication credentials split to protect user from both xss and csrf attacks and your own app is fine there are theoretical ways for an attacker to deal with it if he targets specific user/app, so like any security measures it's just a way of minimizing risks.

Realy good and simple example of xss attack

I agree. I does not matter if you store any information locally, no matter if it is sensitive or not. Also it does not matter if you store it in a cookie or in localStorage. You can manipulate both. When it comes to expiration, this can also be replicated using both methods but it has to be invalidated / checked on the server. So I guess it really does not matter where you store user data as long as you escape any vulnerable input. This can also be implemented using multiple layers: E.g. validate input on frontend if possible or validate request params / body by type (number, string, boolean) and format (isEmail, isUUID, isLowercase) Next would be to validate before inserting into your database on a model / entity level. Most ORMs provide this feature out of the box. Last option would be to validate against any database schema (Database Datatypes). Of course you should catch as many validation checks upfront but just in case, you have multiple layers of security

How about we store the token in the application level variables. Will an XSS attacker be able to access that using some malicious JavaScript ? Is there a way to go that route where we don't use local or session storage or cookies. App makes a request for token every first call it makes to the server. I understand we will not be able to use features like stay logged in etc. but wont it be much secured ? I may be wrong please shed some light if possible. I know it is a very old video to comment now :)

thanks for the video really helpful

The reason why a HttpOnly cookie would be better is because the attacker doesn't get the actual JWT. For a single application you're right in that it won't make such a big difference, but the same JWT may be valid across different services so even if one service is vulnerable you'd want to avoid this extending to all other services sharing the same authentication method too.

wait maybe im not understanding this, but are xss attacks only possible if you implement something that allows users to run any html? I can't really picture myself doing that in any scenario...

Hey Ben, wanted to ask you to do something like your "chosing framework" video but about authentication (the one where you presenting a login behind choosing Gatsby CRA or Next). Do you think there is some thought process that we can have to go with cookie/local/memory, or it's all just semantics?

What if we encrypt JWT token before sending it to user? An encrypted token would be useless for attacker if we have some decryption method at the front end.

Content-Security-Policy response http header can be a added security for this, as this http header limits the outside requests of your img, link, scripts, etc.. to only allowed domains. That way even if an attacker can do something on the site but he wont get anything since he is not able to do a request on some domain that is not defined on your CSP.

how you are vulnerable using in memory token with a refresh token in http only cookie like you did on your prev vid? The only downside I found, is that using TokenRefreshLink will only check if the token is valid when you do a request to the server, but if you get the data from the cache, it won't be checked. So maybe adding a timer with the token expiration date would cover that as well

while being a beginner web developer and exploring the ways of safe authentication and authorization, this topic makes me frustrated. but the fart sound under your video makes me a bit calmer, and gives me a mystical hope.

Wow, it's a great video! I found it really useful and learned a couple of things. However, I think in production there are other things about authentication that are just so very difficult to do without a provider. I mean, web security is a whole another world, as developers we can make our best efforts to secure it. My point is, it's not as easy as say, I'm going to use jwt and store it there, for example, if you use JWT as authentication, how do you persist session securely? How invalidate a stolen jwt? All those things can be overwhelming to do it manually, Auth0 for example and other providers have a lot of security mitigations to help with that.

i've seen csrf tokens being used, and those are assigned to the user at random by the server after each request while a user could steal that token, you can also make sure input is escaped, and use request validation, for example nobody can inject any scripts into you db for either xxs or sql injections. you can also sanitize the input so that commands are rendered as harmless strings. these work relatively well i think, although defeating a csrf token system might not be so difficult if you know what the token is before teh user makes a request

So how do you prevent javascript from being injected? That seems like the biggest problem.

Hi Ben, what if we use httpOnly, secure and samesite=strict with cookies. Can we not prevent cookies with these attributes from xss

JWT is a popular choice for authentication and is implemented in many websites using web storage. Honestly, the site should be handling XSS (and most do), be aware of it, but unless it happens, localStorage and web storage in general is fine.

I know this is old, but seeing this in 2021 . . . Two things off the top of my head to consider - *if a request should ONLY be done based on a user's intent, it should require a second factor authentication, this makes this type of vulnerability significantly weaker *if a token could somehow be exfil'd to an external location rather than just have requests sent on your behalf while the app/tab/etc is open, they can make unrestricted requests regardless of app status, also offline introspection of the quality of the token (encryption methods, etc) is easier

What about indexedDB? I assume this is less vulnerable to attacks?

Can subdomains access the same localstorage from the main domain?

Http only cookies mitigate the majority of xss attacks because of the cross origin requests prevention that browsers have enabled by default

What happened to the solution where you store the token in memory?

is it possible to prevent this by actually making regex middleware or something and check whether the query strings are most likely javascript code and reject it if it is

Good explanation. I had never thought about the risk with query-strings on the URL.

Couldn’t you use some regex validation on the input fields that wouldn’t allow users to enter html or javascript?

I completely agree. Having a stash of money under the mattress is not safer than leaving that stash of money on the kitchen table if you haven't prevented the robber from getting into your house, to begin with.

What if you store a token in an encrypted format? Which can be decrypted by environmental variables 🤔? What do you think?

I believe that SameSite cookies address this problem. In this case the cookie is only sent when making a request to the hosting server

What is the difference with going from the textarea again compared to the console ? It’s only dangerous when it’s from the url ?

How to prevent that please, is there any video for that, Maybe i could prevent that in nginx headers ?

what about httpOnly cookie? Im learning about authentication and recently found a nice article explaining the best way is to have jwt in a regular variable, and a refresh token in a httponly cookie

I really did not get the point. How the attacker gets access to clients browser in the first place? Lets say I'm client to your application, logged with username & password on my browser. Now JWT is stored in my browser's local storage. Now how can an attacker has access to my browser to execute js? Those vulnerable input boxes are available to me only & not for attacker right?

So I understand how using third party libraries which are bundled in your JS can make your app vulnerable to XSS. Such as a library looping through localstorage and sending it to their own API / database. But what I don't understand is how this specific example could make your app vulnerable. If a hacker were to replicate what you did, wouldn't they just see their own localstorage being printed? The same goes for phishing scams. Localstorage is domain specific, so if I clicked on a link to some-hacker.com how would they get access to my localstorage for my-site.com?

Usually what i will do will encrypt the data when storing on cookies or localstorage. If hacker manage to get access to storage or cookies, then they need to decrypt those value in order to use the JWT.

That's why you setup input sanitization before officially deploying

Hello Ben, is your previous video still a safe solution?

i still can't wrap my head about how a hacker target executing js on a victim's machine targeting my specific app or even if the attacker spoiled the victim machine and got his localstorage content, how would he relate to which app or website this token belongs !!

You can bake in IP address into the JWT payload. If the request comes from a IP that is not identical from the JWT payload IP, you can automatically deny it. This would dissallow the usage of the JWT from a different IP. rarbg enforces something similar, but for the purposes of preventing web crawlers, and non-human access.

One thing to note if you store the JWT token in local storage and an attacker gets in, they can use the token to make AJAX requested outside of your infected website whereas if it was stored in a Http only cookie AJAX requests would have to be made on your infected website Implication of this? If you have a react front end and a backend and say a mobile app the front end gets hacked by XSS and it’s stored in Http only, shutting down the website temporarily will temporarily solve the issue as no more Ajax requests can be made with the cookie If you stored it in local storage the attacker can send this to a remote server and use it to make Http requests with or without your website meaning you would have to either shut down your backend or change your signing key while your website is down, this would affect all your other microswrvjcws and would make all your mobile / api uses log out

About indexeddb how can attacker inject some payload on it?

i agree that if you're xss'ed you're pwned. like swapnesh said in the comments, cookies can have an expiration time, however even more than that, there is a serverside session as well that you can terminate if you believe you've been compromised (and so even unexpired, valid cookies will fail to do anything). whereas JWTs are typically accepted on without any further check (this is what lets serverless functions be scalable and stateless, altho some people do implement session checks) and therefore its riskier to keep long lived JWTs around in localstorage OR cookies. i had more great discussions in this thread mobile.twitter.com/swyx/status/1133780714988736512

Can't belive stackoverflow didnt have dark mode back then

I believe its the expiration time on cookies that makes them little better than localStorage. Rest you are totally right that once front end compromised it doesn't matter u store data in cookie / localStorage either.

"It's not really that difficult to write code that is vulnerable", he says, while staring at a div with the "dangerouslySetInnerHTML" prop being used.

Different domain cannot get cookie from original domain? Browser won’t send it.

Another hacker example can be: browser.downloads.download(urlToVirus) will work in case browser has acess to device storage which most people grant.

Whats your opinion on the double cookie method? 1. Separate the header & payload from the signature. 2. Store the header & payload into a secure cookie, as a string. Optional: including a random string, which can act as the redis key for scaling user session. 3. Store the signature as a httponly, secure cookie, as a string. Optional: with the random string from step 2, store the signature into redis, where the key is the random string and value is the signature. That way the client will never have 100% access to the token, but then again as I'm typing this, if you are vulnerable to XSS then it doesnt matter lol.

Ok, Ben, now what? You just told be that it doesn’t matter if I store my token in local storage, because if I'm vulnerable to XSS, they could also, you know, get access to that or just do the fetches on my account without my permission, right?

can u also share your source codes?

Really good example why one shouldn’t use dangerouslySetInnerHTML. One good practice is to use CSP headers which will prevent attacker ”calling home” with malicious code (eg. sending your JWT to attacker). This also protects you from similar attacks if third party libraries would contain malicious code. But even with CSPs attacker can still make calls on your whitelisted endpoints.

its ok to always open the third gate

but like if you render unsafe without a clear reason and respective measures you should go back to the drawing board. ive maybe experienced it 1-2 times that this feature had to be used

Remember XSS is always possible with an extension.

does the use of Auth0 solve the problem?

How would you be vulnerable using cookie httpOnly and domain?

How would you get someone else to run those codes in their browser? I see you just using those codes in your own browser.

You could use XSRF/CSRF pattern as a parity token. For example store your auth token in cookies (http only and secure - only https) and a second jwt token in your local/session storage, that way an attacker can possibly only get one token at a time, so either XSS or XSRF... but your API expects both tokens. JWT can be set to be vaild for a certain time period, the XSRF token does not need to be as strikt as the auth token.

This would not happen if you sanitize the HTML before dangerously setting it in that div.

Here's a counter example: Let's assume a hypothetical situation. An app sanitizes ALL user input without exception. Is it still unsafe to store jwt in localstorage? It seems like the XSS example doesn't really apply to modern webpages, as you have shown you need to go out of your way to even make your site vulnerable in React. Waiting for your feedback, thanks :)

The best approach I have come to learn is to not store it anywhere but in memory. This would cause your app to be unable to refresh without losing session, but there is a browser event that runs before refresh. You can essentially put your JWT in sessionStorage or localStorage during this event and remove it as soon as your app reloads. That way you only keep you token in insecure storage when it is absolutely necessary. And you give very little time for an attacker to use your token if at all.

There are ways to block inline javascript completely in html. This can solve the problem if your app is written in a separate app.js file.

The http only cookies are only sent to the origin that have created them. So the request to another domain will not have cookies in it and it occurres to be safer then localstorage . Please correct me if I am wrong.

Can we not restrict the domain to which the cookies are sent?

I Still prefer cookie storage. You still can't read the cookies, you can only make request with them. JWT on local storage can be read and then taken to another PC and properly impersonate a user. Secondly if the frontend is XXS free, they will have no way to make request on behave of a user using cookies. While if storing JWT in local storage, if an XSS runs on your machine, they can still take those tokens and simulate authentication on their machine.

Cookie with fixed domain and secure cannot get xss. Plus JS can be disabled for some cookie, I mean JS can't access such cookies.

Hey Ben, thanks for all your vids. I have this idea, I don't know if this will work, just a newbie here trying to learn things and all. What if before we store the token locally, we encrypt it first, so that the available "token" locally is not the actual token itself. You know, just thinking. Sorry, newbie here.

Reading comments makes me extremely sad

I'm always hungry so I get cookies

Hey Ben, thanks for the video! Can we store our JWT token in .env file?

What you say is true, but I will retort that localStorage is a lot easier to read and access than cookies are, or any type of session. localStorage, if I'm not mistaken, is readable from anyone's session. Fred can read Daphne's token as long as they use the same computer, with or without XSS, XSS just makes it easier. Session storage is a lot harder to read without being the user, especially if the session is stored server-side.

But some one might as well just do to developer tools.. and get it... if in pc

The New "SameSite" cookie will help to fix the issue for the cookie scenario you mentioned.

Just don't keep tokens around for too long, validate your inputs, both front and backend

Encrypting values in localstorage is a great option

Have you tried setting the httpOnly flag on your cookies?

I hope till today, you won't save jwt in localStorage :))

how about this: save the token in memory. save to local storage when page is unloading. When page is open again, read token from local storage to memory, then delete local storage. So when single page app is running, there is nothing in localstorge.

You should do HTTP only cookies!

I'm new to all this, but the OWASP cheat sheet seems to say you can defend against this using a 'fingerprint' or user context: github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.md#token-sidejacking Explained a bit better here in the update this year: stackoverflow.com/questions/54258233/do-i-have-to-store-tokens-in-cookies-or-localstorage-or-session Would love to see a JS implementation of the first link

Big oof. 1. csrf tokens in headers 2. http only, secure cookies 3. content policy p.s. bonus point, Google PASETO

what is the solution?

Cookies are definitely better for storing jwt tokens with the added level of security using HttpOnly which prevents JS from seeing the cookie and Same-Site which only allows same domain to see the cookie. But again if you're writing code that's vulnerable there's no helping that.

I think a good way to fight against xss maybe is save some sort of device information hash, detect if the device changed to ask re enter the password.

What about storing the JWT in Redux Store?

One can run javascript even by editing inspect > element

Clean your inputs y'all. Don't let your users write any javascript.

why not just use CSP: connect-src? try to send a fetch request on twitter, somewhere other than twitter

So here is my 2 cents (and I might be completly wrong here, and I havent seen your other video about this yet) When you store your information in localstorage, you can get your session stolen. So someone else can be connected as you and do some sort of multi-step hack (do a request, have to wait for someone to accept your request do something else). And they can do it at anytime of the day when ever they want to. If you store your information in a http only cookie, the only time you can get hacked, is when you are currently on a hacked paged. As soon as you close the page, the hack is over. There is no way for the hacker to make other requests. With this idea, if you hacked thousands of account that were stored in localstorage, you could later launch a attack against the website where everybody do the same action at the same time, but if you used http only cookie, even if you haved hacker thousands of account, there might be only 20 currently online that will launch the attack. But then again, not a security expert, and I might be wrong.

use BFF instead, don't trust the client ever

look up the definitions. one is time based (session/activity) the other is space based (local/area).

The title of the video is misleading. This video is about xss. But you get attention from people to watch the vide bu giving a wrong title.

Lol - of course it’s not hard to write a vulnerable react app if you use dangerouslySetInnerHtml. Duh.

get to the point.. ahhmm ahhhm jesus christ these people on youtube. 15minutes of boredom.