Depends. If its javascript on a page only the client can see, and changes arent reflected, and any important tokens are stored as cookies that are http Only and secure, i dont think there is much that can be done. Well of course if its under the form of a link etc it can be used to social engineer people but thats a whole other story. Correct me if i'm wrong!
@@al-ft1ng Instead of obtaining the sessionId to make malicious requests on behalf of the user, the attacker could just make those requests on the user's machine.
THIS IS NOT TRUE AT ALL. Cookies marked as server only can not be accessed by javascript. Thats where you put important things like session information. The browser saves it but its isolated from ALL JS. For all professional websites your login information is kept in server side only cookies that XSS can not touch.
Your advice is like: Don't store your everyday jewelry in your house as if somebody finds as key under backdoors carpet he can steal them. Instead lock them in a bank cell and never take out of there. LS and cookies are absolutely different things for different perposes. It's not a problem of LS that it can be accessed. If you need this data in the script you need to get it from somewhere and http-only cookies aren't for that.
And we also have to mention an XSS attack will not care where the things are stored. An XSS attack will not even need your tokens, it simply needs an active browser tab. That user session can be encrypted by a team of NSA agents, it won’t matter, as long as a tab is active an XSS attacker can and will just use that.
@QwDragon Agree, Joshua is like level 1 of Theo Rant, that dude is complete BS, he even tell people to pronounce coding terms properly as they were calling it wrong.
and if it's sensitive information, generally you don't want to access it from your script - for example AWS Cognito stores your session cookie & details in localStorage, for some reason...
HttpOnly cookies are _not_ like locking them in a bank. instead it's like like actually wearing your jewelry. you can't see them yourself (let's assume it's a necklace/lanyard), but everyone else can tell it's you by looking at the jewelry.
@@philheathslegalteam while it's true that XSS can do bad things even with just an active browser tab, the entire point of XSS is to exfiltrate sensitive data. and if the only sensitive data isn't accessible from JS, then XSS becomes a lot less useful for an attacker. (note that cookies in general are only sent on requests to the domain on which they are stored...) tl;dr: yes removing sensitive data from localStorage isn't a panacea. but you wouldn't _leave your front door wide open_ if it's an option to put a lock on it...
josh you are making great videos but sometimes you are making videos with half baked knowledge which leads people wrong direction. Local storage data is only accessible within the same domain and protocol that created it, restricting its cross-domain usage. if your website is vulnarable to xss localstorage or cookie doesnt do much. Next time please search more about a topic before making video.
@@M.FaisalAmin won’t matter. XSS will just use active browser session. Think of it as an attacker controlling your mouse and keyboard, only it happens in a sandboxed browser tab.
Sure, cookies are not vunerable to XSS, but they're vunerable to CSRF. And just like how CSRF can be circumvented using CSRF tokens, XSS can also be circumvented by using two tokens, one stored in local storage and one stored in a secure cookie (usually called access and refresh tokens though those specific names entail additional functionalities). Also to clarify, document.cookie is a string that's the concatination of all the cookies stored. It's undefined in this example, but if you have multiple cookies, among which a few are secure (http only), document.cookie would be defined and will contain all the non-secure cookies.
For me refresh token is kept in cookie. Access token is not stored anywhere. Access token(valid for 10 minutes) stays in State Manager and used while making request. I intercept every request and add Authorization header to request. If access token is expired new token is fetched from server then appended to header. When user fully reload page new acess token is acquired to make request. XSS is very old attack every template and framwork are immune to it. If you are allowing user to post html to display in page you need to sanitize it. CSRF is not a problem in json api based website. As the Access Token is sent in header not cookie. Today everyone is saying don't roll your own auth. But I am not in support of this. You should roll auth few times in starting journey just to understand how it works and what are are possible vulnerabilities. How the work flow work. Why choose session or JWT. What are tradeoffs. After some time you will feel you are repeating the same thing everytime now you have two way 1) create own auth lib based on what we have learn so far or 2) use any auth lib available I prefer 1st way because you know what you have written and how that work. You will be able to integrate it easily. Also auth service providers charge lot of money.
@@joshtriedcoding You are correct, but Web Dev Simplified made some mistakes (sameSite: none, wtf?) in his explanation, and it's already outdated (Chrome does not allow that anymore). Could you please create a video on this topic? You're fantastic!
I can understand the "not put sensible informations" in the LocalStorage, it apply to multiple scenario not only this one. Other than that the "LocalStorage was a mistake..." it's only a clickbait title.
I think the problem with LS is that it’s a very simple storage API meaning inexperienced devs will feel inclined to just use that for storing sensitive information. LS is by no means a mistake, but I can see how you would make that point. I myself started out with putting tokens in LS
@@cranberry888 I mean the raw token shouldn’t be stored anywhere except the backend. Once you obtain the token, you can either encrypt it or create a session ID which refers to the token in the database. In both cases the recommended approach would be to put this information in a cookie and return it to the client (with HTTP only flag set, and preferably other cookie securing attributes, like Secure and Domain)
@@jitxhere No, XSS is a different problem (injecting data without sanitizing first) Just switching a few properties in your cookies doesn’t fix the problem.
@@jitxherexss and csrf are different attacks. you should always use a secure double submit cookie pattern to mitigate csrf. which makes use of secure and httponly flags.
I think your points are not really valid for calling out localStorage to be a mistake. It has flaws, but cookies also have flaws. In fact everything has flaws, because it's man-made. If you're afraid that your app might be vulnerable to XSS attacks, then make your app more XSS proof rather than stop using localStorage. I mean XSS attacks can target a whole lot of different areas than just localStorage. The attacker has control over the whole JS part of the victim. They can do whatever JS is capable of doing, not just accessing localStorage or cookies. In addition to making your app more XSS proof, you can also make your localStorage more secure by encrypting its data. In my opinion that might be overkill but if you're paranoid, sure, go ahead.
@kapobajza3708 - I wanted to reply along the same lines, then I remembered its just the cycle that Tech Tubers go through: that grind for content. Push out click bait stuff that is essentially meaningless, but they made their quota for the almighty algorithm. 😵💫
@airixxxx Its a beginner's thing, the way he talks about is like targeting developer's, made them feel like they just started coding, while showing himself of some kind of 16 year's old Lester's character teaching live.
@@5omebody from what i know, this is only problem if you are vulnarable to xss attacks. And if u are then its game over anyways. You should prevent your website form this and you can store it your tokens in local storage i dont see problem here. Http cookies are also vulnarable to csrf so u need to handel that aswell if u use it. I can be wrong on this but from my understanding if you use modern frameworks and libraries like react you dont have any problems with xss also u need to secure your api. And you can use local storage with no problem.
The solution to XSS is to sanitize your inputs and outputs, not to never use localStorage. If you're using a popular framework it's probably already sanitizing your outputs for you even. I feel like this video is mixing up a bunch of topics that don't necessarily need to be.. it comes across as a bit unfocused to me
@@incarnateTheGreatno. Supabase cookies are not marked as httpOnly. It doesn’t really matter what you use for sessionIds. If I execute a good XSS attack I can just steal all your information by using your valid credentials directly from your own browser.
You are using localstorage in the wrong way. Save theme data there, what page the user is on, on a table. Localstorage was not a mistake what makes you think you are smarter than a whole corporation. They thought about long and hard.
Cookies were (kind of) invented to solve state management problems in MPA many, many years ago. Cookies travel with HTTP requests. So, when you make an HTTP request from PageA to the server to navigate to PageB cookie data will be on HTTP headers unless you remove it on the server during response generation
This guy just thought he outsmarted W3C without even reading the specs first lol. Worst things script kiddies like this and that Theo guy are consumed by juniors who actually buy into it all, which is sad for the software industry.
Damn it. I wrote this massive comment that took 10min to write, on how ProtonMail uses encrypted local storage to make their email content searchable, only for UA-cam to auto delete my comment. FKN hell.
Local storage was not a mistake. It has its uses. Even cookies are not secure if you don't have the correct configuration. People should stop using local storage for what it is not meant for lol.
Also worth mentioning that chrome extensions can inject javascript to the website. So even if your website is not vulnerable to xss attacks, chrome extensions can still take advantage of local storage.
i dont understand this. If your backend is secured why this matter? Im trying to figure it out. Like from my understanding local storage is specifig to that page so user can only hurt himself and get his access token. He cant inject his script to your db which means he cant do anything if u prevent xss. But on the other hand if u use http cookies then there is also csrf thing when u are in a hackers website and it send request to the api of your app and automatically browser send cookie because it is the same domain as cookie. And then hacker can manipulate that . I would like to hear explanation if im wrong on this.
Bro i think LS just works on a single domain and seperate for every user so there is really no way for hackers to access someone elses LS and using a cookie as an alternative wont change anything, hackers only have access to their data.
Nice video, but i have a question. When using a express backend that is sending the JWT access and refresh token, and we store them inside next-auth jwt token, when we load a page with getSession and serving to user the session with the two tokens, we are getting the same problem as the video presented right? Because The main question is if we access the nextauth jwt, and send the accesstoken stored in header, we are serving this token in js right?
If http communication causes the cookie to be sent, wouldn't it be enough for me to simulate a request to my server to capture the user session with an http only cookie?
Not if same origin is on. But this won’t matter in the event of XSS. It won’t even need tokens it has full control of the page as it can do whatever JS can do, like clicking buttons to transfer bank money.
as plan B... just don't create a XSS vulnerability. This days you need to conciously make a decision to throw an XSS vulnerabilty in there. You don't really use innerHTML generally speaking, and all the frameworks who use it under the hood always sanitize beforehand
"Just dont create a vulnerability" is pretty easily said, but it's actually great how hard modern frameworks make it. Especially in React with their naming of "dangerously". I remember needing innerHTML at work in SolidJS a while back and while it's just called "innerHTML" there, eslint does pick up on it and warn you
@@paw565 I would honestly just store it in a variable, if you really need it in localstorage, yeah, sure, just be sure to not throw innerHTML around and you should be fine. And if you do, just use a sanitizing library and let the string run threw it or just create a TextNode I think it's called, add it to the text node and then add it to the DOM (text node should sanitize if I'm not mistaken).
@@paw565 the only plausible problem with storing JWT tokens (or anything else encrypted, for that matter) in localStorage is that one can easily copy the token and use it in a different browser, in a completely different location. Theoretically one can be hijacked like this, but in practice this is not your problem. Anyway setting up cookies in nextjs is supposed to be easy?
where do you think the user gets his cookies from. if the xss attacker instead of taking the cookies from the browser, he will just ask for more cookies from the server in behalf of the user. ... there you go. once your website is xss attackable.. you are doomed
This isn’t great I’m afraid. Security is a bit more involved than this. JWT is where you should be storing secure information. Only enough o authenticate and look up values on server side. The JS only needs to know enough to pass in headers and cookies
but don't JWTs usually contain all the sensitive information (note: not necessarily _secure_ information)? if anything, you'd want a plain session cookie instead, so that it stores _no_ data
could be just youtube with its comment deletion. maybe "leaving react world" was detected as self harm or something lol. sometimes really normal comments get deleted for no reason
@@jp0678OK, i am sure some funny stuff is going on , after refreshing the page my reply is gone too. i replied to you but it got lost. parent comment of me still shows "2 replies". this is going to be the third one.
http only cookies is interesting, thanks for teaching about that. One way or another, it definitely seems like not giving js access to sensitive data that it doesn't need access to is a good idea. It's essentially tightening permissions and I can't imagine arguing that that's a bad idea. At worse there's no negative besides the time it took to transition to using a cookie instead. If relying on js having access to the token is in some way fundamental (not sure what that situation would be, but I'm sure it exists), I don't think I'd restructure just to make a http only cookie instead. But if it's an easy change I'd go for it. When building a new project I don't really see a drawback to just implementing it this way instead either. "LocalStorage was a mistake..." is a very clickbaity title though. I'd be worried about newer programmers feeling like they need to avoid using LocalStorage because of it.
but surely it doesnt matter because in that onerror function they can still call your api and do whatever they want on the client anyway and if they really for some reason want your access token on their servers they can just regenerate your tokens on the client
You fail to mention that cookies get transmitted on every HTTP request ... your "advice" provides not enough context for you to claim that local storage is "not secure" ... Sensitive Information should never live on client-side anyway .. yeah sure session IDs and short lived access tokens are fine but other than that you want to avoid storing sensitive state on the client in anyway what so ever.
You're trying to steal other people's data by having a pièce of code that you injected into a victim site, run on their machine, and possibly be able to send that data to you (using a REST API of your choosing). The dev tools in this video are just a way to show you how this data is accessible by such an html+js code.
3 weeks ago you were talking about stylex "the f*ck9 tailwind killer". i watched your video and then i went exploring it after wasting hours i realized it is nothing. i mean dont make a video that does not help developers
I love how some modern apps will set an http only token but put a refresh token in local storage with no protections against converting those refresh tokens for access tokens. Good video to highlight security.
Yeah that’s completely valid and good practice. It doesn’t matter if your tokens are stored in httpOnly secure cookies and placed under SHA256 encryption, if your site is vulnerable to XSS I’ll just use the current browser session to execute whatever I see fit. There is no cure if your site is vulnerable to XSS. The only cure is to invalidate all sessions immediately, delete all refresh tokens and fix the XSS vulnerability.
The coding concepts I've learnt from josh has really improved the way i approach any problem. But can you give a specific example on how to use cookies in next js
i learned this stuff when i was learning node.js in 2020. and since then, I am doing this in every project i made. if you want to make a video daily, then prepare some good stuff.
Nice video, albeit a bit mistitled.. LocalStorage was not a mistake, it is just that people (myself included) started using it as a wrong tool for resolving the challenges we had at hand
Ontop of all this try making use of more security stuff like html tags for security purposes. Just try stuff and if it breaks your site undo it and then try again :D
if someone can find a way to execute javascript on your app, then you are already screwed, doesn't matter if you token is in cookies or local storage
Depends. If its javascript on a page only the client can see, and changes arent reflected, and any important tokens are stored as cookies that are http Only and secure, i dont think there is much that can be done. Well of course if its under the form of a link etc it can be used to social engineer people but thats a whole other story. Correct me if i'm wrong!
@@al-ft1ng Instead of obtaining the sessionId to make malicious requests on behalf of the user, the attacker could just make those requests on the user's machine.
Doesn't matter if it's JS or not. If it's malicious code that WILL execute, then you are at risk.
THIS IS NOT TRUE AT ALL. Cookies marked as server only can not be accessed by javascript. Thats where you put important things like session information. The browser saves it but its isolated from ALL JS. For all professional websites your login information is kept in server side only cookies that XSS can not touch.
Your advice is like: Don't store your everyday jewelry in your house as if somebody finds as key under backdoors carpet he can steal them. Instead lock them in a bank cell and never take out of there.
LS and cookies are absolutely different things for different perposes. It's not a problem of LS that it can be accessed. If you need this data in the script you need to get it from somewhere and http-only cookies aren't for that.
And we also have to mention an XSS attack will not care where the things are stored. An XSS attack will not even need your tokens, it simply needs an active browser tab. That user session can be encrypted by a team of NSA agents, it won’t matter, as long as a tab is active an XSS attacker can and will just use that.
@QwDragon Agree, Joshua is like level 1 of Theo Rant, that dude is complete BS, he even tell people to pronounce coding terms properly as they were calling it wrong.
and if it's sensitive information, generally you don't want to access it from your script - for example AWS Cognito stores your session cookie & details in localStorage, for some reason...
HttpOnly cookies are _not_ like locking them in a bank. instead it's like like actually wearing your jewelry. you can't see them yourself (let's assume it's a necklace/lanyard), but everyone else can tell it's you by looking at the jewelry.
@@philheathslegalteam while it's true that XSS can do bad things even with just an active browser tab, the entire point of XSS is to exfiltrate sensitive data. and if the only sensitive data isn't accessible from JS, then XSS becomes a lot less useful for an attacker. (note that cookies in general are only sent on requests to the domain on which they are stored...)
tl;dr: yes removing sensitive data from localStorage isn't a panacea. but you wouldn't _leave your front door wide open_ if it's an option to put a lock on it...
josh you are making great videos but sometimes you are making videos with half baked knowledge which leads people wrong direction. Local storage data is only accessible within the same domain and protocol that created it, restricting its cross-domain usage. if your website is vulnarable to xss localstorage or cookie doesnt do much. Next time please search more about a topic before making video.
Always use secret local storage, and you are good to go
Chrome is literally about to disable cookies. It is such bad advice!
@@M.FaisalAmin won’t matter. XSS will just use active browser session. Think of it as an attacker controlling your mouse and keyboard, only it happens in a sandboxed browser tab.
@@twocsiesno it’s not it’s going to disable third party cookies
XSS works on the same domain. You're the one in need of more searching
Sure, cookies are not vunerable to XSS, but they're vunerable to CSRF. And just like how CSRF can be circumvented using CSRF tokens, XSS can also be circumvented by using two tokens, one stored in local storage and one stored in a secure cookie (usually called access and refresh tokens though those specific names entail additional functionalities).
Also to clarify, document.cookie is a string that's the concatination of all the cookies stored. It's undefined in this example, but if you have multiple cookies, among which a few are secure (http only), document.cookie would be defined and will contain all the non-secure cookies.
They're only partially susceptible to CSRF exploits. See Samesite attribute for cookies.
CSRF is a whole different story, I really enjoyed Web Dev Simplified's video on that a couple months back
For me refresh token is kept in cookie. Access token is not stored anywhere. Access token(valid for 10 minutes) stays in State Manager and used while making request. I intercept every request and add Authorization header to request. If access token is expired new token is fetched from server then appended to header. When user fully reload page new acess token is acquired to make request.
XSS is very old attack every template and framwork are immune to it. If you are allowing user to post html to display in page you need to sanitize it.
CSRF is not a problem in json api based website. As the Access Token is sent in header not cookie.
Today everyone is saying don't roll your own auth. But I am not in support of this. You should roll auth few times in starting journey just to understand how it works and what are are possible vulnerabilities. How the work flow work. Why choose session or JWT. What are tradeoffs.
After some time you will feel you are repeating the same thing everytime now you have two way 1) create own auth lib based on what we have learn so far or 2) use any auth lib available
I prefer 1st way because you know what you have written and how that work. You will be able to integrate it easily. Also auth service providers charge lot of money.
@@joshtriedcoding You are correct, but Web Dev Simplified made some mistakes (sameSite: none, wtf?) in his explanation, and it's already outdated (Chrome does not allow that anymore). Could you please create a video on this topic? You're fantastic!
where can i learn about your suggested approach
I can understand the "not put sensible informations" in the LocalStorage, it apply to multiple scenario not only this one. Other than that the "LocalStorage was a mistake..." it's only a clickbait title.
I think the problem with LS is that it’s a very simple storage API meaning inexperienced devs will feel inclined to just use that for storing sensitive information. LS is by no means a mistake, but I can see how you would make that point. I myself started out with putting tokens in LS
@@AnsisPlepiswhere should I put tokem instead? indexedDb? cookie
I'm taking token from LS then intercept it to cookie
@@cranberry888 I mean the raw token shouldn’t be stored anywhere except the backend. Once you obtain the token, you can either encrypt it or create a session ID which refers to the token in the database. In both cases the recommended approach would be to put this information in a cookie and return it to the client (with HTTP only flag set, and preferably other cookie securing attributes, like Secure and Domain)
xss attack doesn't need to steal your cookie, it can just steal your bank money by making requests using the cookie
This, it really doesn’t matter where you store it. If you have an XSS vulnerability you’re screwed and should invalidate all sessions ASAP.
Does making cookie http only, secure and samesite prevent XSS and CSRF??
@@jitxhere No, XSS is a different problem (injecting data without sanitizing first) Just switching a few properties in your cookies doesn’t fix the problem.
@@jitxherenope 😂
@@jitxherexss and csrf are different attacks. you should always use a secure double submit cookie pattern to mitigate csrf. which makes use of secure and httponly flags.
I think your points are not really valid for calling out localStorage to be a mistake. It has flaws, but cookies also have flaws. In fact everything has flaws, because it's man-made.
If you're afraid that your app might be vulnerable to XSS attacks, then make your app more XSS proof rather than stop using localStorage. I mean XSS attacks can target a whole lot of different areas than just localStorage. The attacker has control over the whole JS part of the victim. They can do whatever JS is capable of doing, not just accessing localStorage or cookies.
In addition to making your app more XSS proof, you can also make your localStorage more secure by encrypting its data. In my opinion that might be overkill but if you're paranoid, sure, go ahead.
Just use cookies that js can't access
@kapobajza3708
- I wanted to reply along the same lines, then I remembered its just the cycle that Tech Tubers go through: that grind for content. Push out click bait stuff that is essentially meaningless, but they made their quota for the almighty algorithm. 😵💫
Encrypting localstorage is security by obscurity, so basically bullshit
@@justthatoneguynicolai won’t protect from XSS
thats why you add anti csrf token@@philheathslegalteam
Now he banned local storage. The channel should be renamed as "Josh is still figuring out Coding"
He banned local storage for sensitive things only.
@airixxxx Its a beginner's thing, the way he talks about is like targeting developer's, made them feel like they just started coding, while showing himself of some kind of 16 year's old Lester's character teaching live.
it's not like localStorage is particularly useful for storing anything other than user settings (read: non-sensitive info) anyway...
@@5omebody from what i know, this is only problem if you are vulnarable to xss attacks. And if u are then its game over anyways. You should prevent your website form this and you can store it your tokens in local storage i dont see problem here. Http cookies are also vulnarable to csrf so u need to handel that aswell if u use it. I can be wrong on this but from my understanding if you use modern frameworks and libraries like react you dont have any problems with xss also u need to secure your api. And you can use local storage with no problem.
@@axlYT yeah, that's fair. but tbh i don't think it hurts to have extra layers of security
I hung my front door key from teh screen door, now someone has taken all my stuff. Don't use doors.
The solution to XSS is to sanitize your inputs and outputs, not to never use localStorage. If you're using a popular framework it's probably already sanitizing your outputs for you even. I feel like this video is mixing up a bunch of topics that don't necessarily need to be.. it comes across as a bit unfocused to me
my god dude, learn how the web works. cookies do nothing for you if an attacker is in, he can make requests that pass along the cookie
for viewers: it's ok to use LS :)
(except for sensitive info of course, as noted in the description)
@@5omebodynuh uh, if u get an XSS attack youre fucked no matter what
josh u got me back into coding i use ur stuff day to day and i love how you structure your projects! thank you for all that you do
Summary "USE COOKES" for private things
Is this why Supabase uses Cookies?
@@incarnateTheGreat maybe
@@incarnateTheGreatno. Supabase cookies are not marked as httpOnly.
It doesn’t really matter what you use for sessionIds. If I execute a good XSS attack I can just steal all your information by using your valid credentials directly from your own browser.
Cookies with http only and samesite attributes
You are using localstorage in the wrong way. Save theme data there, what page the user is on, on a table. Localstorage was not a mistake what makes you think you are smarter than a whole corporation. They thought about long and hard.
Josh can you create a vedio about how we can stroe the token from api response and use it in the server side in next js ?
This will be great for single page websites but I need to transfer cookie data from one page to another
Cookies were (kind of) invented to solve state management problems in MPA many, many years ago. Cookies travel with HTTP requests. So, when you make an HTTP request from PageA to the server to navigate to PageB cookie data will be on HTTP headers unless you remove it on the server during response generation
whats the white board app you using at 4:25
cookies still not secure
look for CSRF :/
This guy just thought he outsmarted W3C without even reading the specs first lol. Worst things script kiddies like this and that Theo guy are consumed by juniors who actually buy into it all, which is sad for the software industry.
I just don't agree with this vdeo, and the topic just not for this channel, 99% of people watching ur content know what u talked about in this video
What is the solution to if I use multiple pages and not a singular page and communicate data?
A database
Where should I put them? Inside a div of course. If only I know how to center them.
So what are the alternatives to local storage?
Uh,
but you didn't show how to set the HTTP-Cookie header server side???
I mean, sure, Local storage is insecure if you store in plaintext?
This is such incomplete and utterly garbage advice
So we have to use AES encryption layer
Damn it. I wrote this massive comment that took 10min to write, on how ProtonMail uses encrypted local storage to make their email content searchable, only for UA-cam to auto delete my comment. FKN hell.
Local storage was not a mistake. It has its uses. Even cookies are not secure if you don't have the correct configuration. People should stop using local storage for what it is not meant for lol.
Also worth mentioning that chrome extensions can inject javascript to the website. So even if your website is not vulnerable to xss attacks, chrome extensions can still take advantage of local storage.
Extensions can also monitor requests too, so I'm pretty sure they would be able to get cookies just by inspecting the headers in outgoing requests
i dont understand this. If your backend is secured why this matter? Im trying to figure it out. Like from my understanding local storage is specifig to that page so user can only hurt himself and get his access token. He cant inject his script to your db which means he cant do anything if u prevent xss. But on the other hand if u use http cookies then there is also csrf thing when u are in a hackers website and it send request to the api of your app and automatically browser send cookie because it is the same domain as cookie. And then hacker can manipulate that . I would like to hear explanation if im wrong on this.
Bro i think LS just works on a single domain and seperate for every user so there is really no way for hackers to access someone elses LS and using a cookie as an alternative wont change anything, hackers only have access to their data.
Nice video, but i have a question. When using a express backend that is sending the JWT access and refresh token, and we store them inside next-auth jwt token, when we load a page with getSession and serving to user the session with the two tokens, we are getting the same problem as the video presented right? Because The main question is if we access the nextauth jwt, and send the accesstoken stored in header, we are serving this token in js right?
If http communication causes the cookie to be sent, wouldn't it be enough for me to simulate a request to my server to capture the user session with an http only cookie?
Not if same origin is on. But this won’t matter in the event of XSS. It won’t even need tokens it has full control of the page as it can do whatever JS can do, like clicking buttons to transfer bank money.
as plan B... just don't create a XSS vulnerability. This days you need to conciously make a decision to throw an XSS vulnerabilty in there. You don't really use innerHTML generally speaking, and all the frameworks who use it under the hood always sanitize beforehand
So is it OK to store jwt access token in localstorage? I had a big issue with setting cookies in next js, so I decided to gave up on them.
"Just dont create a vulnerability" is pretty easily said, but it's actually great how hard modern frameworks make it. Especially in React with their naming of "dangerously". I remember needing innerHTML at work in SolidJS a while back and while it's just called "innerHTML" there, eslint does pick up on it and warn you
@@paw565u can use next-auth library in next js, which automatically sets cookie and also csrf.
@@paw565 I would honestly just store it in a variable, if you really need it in localstorage, yeah, sure, just be sure to not throw innerHTML around and you should be fine. And if you do, just use a sanitizing library and let the string run threw it or just create a TextNode I think it's called, add it to the text node and then add it to the DOM (text node should sanitize if I'm not mistaken).
@@paw565 the only plausible problem with storing JWT tokens (or anything else encrypted, for that matter) in localStorage is that one can easily copy the token and use it in a different browser, in a completely different location. Theoretically one can be hijacked like this, but in practice this is not your problem.
Anyway setting up cookies in nextjs is supposed to be easy?
where do you think the user gets his cookies from.
if the xss attacker instead of taking the cookies from the browser,
he will just ask for more cookies from the server in behalf of the user.
... there you go.
once your website is xss attackable.. you are doomed
This isn’t great I’m afraid. Security is a bit more involved than this.
JWT is where you should be storing secure information. Only enough o authenticate and look up values on server side.
The JS only needs to know enough to pass in headers and cookies
but don't JWTs usually contain all the sensitive information (note: not necessarily _secure_ information)? if anything, you'd want a plain session cookie instead, so that it stores _no_ data
@@5omebody no, JWT is secure. it's an encrypted payload.
wow Josh you deleted my comment because i said i am leaving react world? what's wrong with what i wrote?
could be just youtube with its comment deletion. maybe "leaving react world" was detected as self harm or something lol. sometimes really normal comments get deleted for no reason
@@jp0678 i hope so, lol:)
@@jp0678OK, i am sure some funny stuff is going on , after refreshing the page my reply is gone too. i replied to you but it got lost. parent comment of me still shows "2 replies". this is going to be the third one.
Who the fuck would ever save sensitive things in localstorage?
Him :)) who made this video
You did not demonstrate an actual attack. All things you show is just "imagine" and an "if" scenario that did not happen at all
http only cookies is interesting, thanks for teaching about that. One way or another, it definitely seems like not giving js access to sensitive data that it doesn't need access to is a good idea. It's essentially tightening permissions and I can't imagine arguing that that's a bad idea. At worse there's no negative besides the time it took to transition to using a cookie instead.
If relying on js having access to the token is in some way fundamental (not sure what that situation would be, but I'm sure it exists), I don't think I'd restructure just to make a http only cookie instead. But if it's an easy change I'd go for it. When building a new project I don't really see a drawback to just implementing it this way instead either.
"LocalStorage was a mistake..." is a very clickbaity title though. I'd be worried about newer programmers feeling like they need to avoid using LocalStorage because of it.
LocalStorage is for saving settings such as dark/light mode, keep logged in, accessibility utils, etc
Yeah private data is usually in sessionStorage
@@v01d_r34l1tySession Storage is the exact same thing man except it's only valid for a session
Ummm i would love to inform you that cookies aren't safe anymore
but surely it doesnt matter because in that onerror function they can still call your api and do whatever they want on the client anyway and if they really for some reason want your access token on their servers they can just regenerate your tokens on the client
Even if this protects against xss what about csrf and even so these solutions are temp as people will find other solutions and methods.
This does nothing to protect against XSS
inam disappointed by this video because I was really enjoying the content until now
this is... misinformation
The server could alternately use CSP to prevent access to injection using nonces.
leaves the door open:
- look how houses are insecure
Problem isn't with local storage, the problem is the people using it the wrong way. Even on the server is you so something wrong you will get hacked
No s shelock
You fail to mention that cookies get transmitted on every HTTP request ... your "advice" provides not enough context for you to claim that local storage is "not secure" ... Sensitive Information should never live on client-side anyway .. yeah sure session IDs and short lived access tokens are fine but other than that you want to avoid storing sensitive state on the client in anyway what so ever.
Good video! What text editor you are using for the explanation? Is this an online Editor?
Now make video on how we can store data in cookies.....
Maybe I'm too dumb, but why do you even need a XSS attack if you just can go in the dev tools.
Dev tools show you your own data, not data of others.
You're trying to steal other people's data by having a pièce of code that you injected into a victim site, run on their machine, and possibly be able to send that data to you (using a REST API of your choosing). The dev tools in this video are just a way to show you how this data is accessible by such an html+js code.
Jesus Fucking Christ, now I understand why react is popular.
great video! http only cookies are amazing.
which software did you use in the animated diagrams?
I started falling asleep exactly when the video stopped with a "boring" screen. So good call to cut it😂
yeah cant have that here, good to hear the vine boom sound effect woke you up hahaha
don't make a video if there is nothing new. unsubscribed
Server side Javascript was a mistake
Can’t we just encrypt data and secret word will be saved in environment value? This way even if the manage get data it is useless or am I wrong?
3 weeks ago you were talking about stylex "the f*ck9 tailwind killer". i watched your video and then i went exploring it after wasting hours i realized it is nothing. i mean dont make a video that does not help developers
React cookie components when?
storing auth token in local storage :))
Yes it’s common practice not insecure.
You can create a wrapper around local storage which encrypts the value when set and decrypts when done get.
Useless. Either script can access data or not. And these cases are not interchangable in almost all cases. No any problems with LS.
Frontend it's not a secure place
Imagine storing anything sensitive on the client side and getting your PR approved
How would you persist auth then?
yes how? @@jitxhere
@@jitxhere if you have actual sensitive data in your application you dont persist auth. Or only persist with access to non sensitive data.
I love how some modern apps will set an http only token but put a refresh token in local storage with no protections against converting those refresh tokens for access tokens.
Good video to highlight security.
Yeah that’s completely valid and good practice.
It doesn’t matter if your tokens are stored in httpOnly secure cookies and placed under SHA256 encryption, if your site is vulnerable to XSS I’ll just use the current browser session to execute whatever I see fit.
There is no cure if your site is vulnerable to XSS. The only cure is to invalidate all sessions immediately, delete all refresh tokens and fix the XSS vulnerability.
Laravel sanctum taught me this a long time ago. Very grateful.
The coding concepts I've learnt from josh has really improved the way i approach any problem. But can you give a specific example on how to use cookies in next js
props for cutting out the boring part lol
i learned this stuff when i was learning node.js in 2020. and since then, I am doing this in every project i made. if you want to make a video daily, then prepare some good stuff.
Impressive, very nice. Let's see Paul Allen's security concerns.
react .. enough said.
Nice video, albeit a bit mistitled.. LocalStorage was not a mistake, it is just that people (myself included) started using it as a wrong tool for resolving the challenges we had at hand
It’s the right tool for this.
Ontop of all this try making use of more security stuff like html tags for security purposes. Just try stuff and if it breaks your site undo it and then try again :D
What, these practices are recommended because you cant just try stuff and pray its safe. Stuff that is unsafe wont break your site by definition.
Can you please make a tutorial using Authjs V5, cookie approach, and server actions. Please!!! 😊
Josh next time chooses any advance topic
TLDR: RTFM
bullshit. wasted my 5 minutes and 5 seconds because luckily i did'nt watched the remaining video. but please write better title and thumbnail.
i like it.. u dont put any secure data stuff on it anyway xD lol.. this is just blubering nonsense. who thinks that way anyway xD omg
Wish the title included a little more context
Local storage is only a risk if you are mid.
ah thats a good solution ENCRYPT ALL YOUR DATA
Mr Josh is a Legend instructor...
indexdb sensitive data. localstorge utility data
Encrypt all your data ... Decrypt when needed... Simple
Love your videos!
Always use secret local storage, like react-secure-storage and you are good to go 🎉 🎉
why cut that 🥲 I'm an Application security engineer and that was the most interesting part of the video for me 🤣
But then u wanna mess with cookies eu laws🫤
The ‘cookies’ law is only about tracking stuff. You don’t need to request permission for basic functionality