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

@al-ft1ng

4 ай бұрын

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!

@pepkin88

4 ай бұрын

@@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.

@akam9919

4 ай бұрын

Doesn't matter if it's JS or not. If it's malicious code that WILL execute, then you are at risk.

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.

@philheathslegalteam

4 ай бұрын

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.

@CookerSingh

4 ай бұрын

@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.

@5omebody

4 ай бұрын

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...

@5omebody

4 ай бұрын

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.

@5omebody

4 ай бұрын

@@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...

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.

@AnsisPlepis

4 ай бұрын

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

4 ай бұрын

​@@AnsisPlepiswhere should I put tokem instead? indexedDb? cookie I'm taking token from LS then intercept it to cookie

@AnsisPlepis

4 ай бұрын

@@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)

Now he banned local storage. The channel should be renamed as "Josh is still figuring out Coding"

@airixxxx

4 ай бұрын

He banned local storage for sensitive things only.

@CookerSingh

4 ай бұрын

@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

4 ай бұрын

it's not like localStorage is particularly useful for storing anything other than user settings (read: non-sensitive info) anyway...

@axlYT

4 ай бұрын

@@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.

@5omebody

4 ай бұрын

@@axlYT yeah, that's fair. but tbh i don't think it hurts to have extra layers of security

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.

@justthatoneguynicolai

4 ай бұрын

Just use cookies that js can't access

@ghume79

4 ай бұрын

@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. 😵‍💫

@maratmkhitaryan9723

4 ай бұрын

Encrypting localstorage is security by obscurity, so basically bullshit

@philheathslegalteam

4 ай бұрын

@@justthatoneguynicolai won’t protect from XSS

@justthatoneguynicolai

4 ай бұрын

thats why you add anti csrf token@@philheathslegalteam

xss attack doesn't need to steal your cookie, it can just steal your bank money by making requests using the cookie

@franklin_waller

4 ай бұрын

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.

@jitx2797

4 ай бұрын

Does making cookie http only, secure and samesite prevent XSS and CSRF??

@franklin_waller

4 ай бұрын

@@jitx2797 No, XSS is a different problem (injecting data without sanitizing first) Just switching a few properties in your cookies doesn’t fix the problem.

@AndrieMC

4 ай бұрын

​@@jitx2797nope 😂

@urssaf343

4 ай бұрын

​@@jitx2797xss 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.

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.

@MrRaitiz

4 ай бұрын

They're only partially susceptible to CSRF exploits. See Samesite attribute for cookies.

@joshtriedcoding

4 ай бұрын

CSRF is a whole different story, I really enjoyed Web Dev Simplified's video on that a couple months back

@abhinavadarsh7150

4 ай бұрын

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.

@CrAzZyKiLleR01

4 ай бұрын

@@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!

@pr55571

4 ай бұрын

where can i learn about your suggested approach

for viewers: it's ok to use LS :)

@5omebody

4 ай бұрын

(except for sensitive info of course, as noted in the description)

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

4 ай бұрын

Always use secret local storage, and you are good to go

@twocsies

4 ай бұрын

Chrome is literally about to disable cookies. It is such bad advice!

@philheathslegalteam

4 ай бұрын

@@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.

@Jaxenormus

4 ай бұрын

@@twocsiesno it’s not it’s going to disable third party cookies

@sydneymccarty5501

4 ай бұрын

XSS works on the same domain. You're the one in need of more searching

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

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 ?

Summary "USE COOKES" for private things

@incarnateTheGreat

4 ай бұрын

Is this why Supabase uses Cookies?

@boi-kheko

4 ай бұрын

@@incarnateTheGreat maybe

@philheathslegalteam

4 ай бұрын

@@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.

@jitx2797

4 ай бұрын

Cookies with http only and samesite attributes

whats the white board app you using at 4:25

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?

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

So what are the alternatives to local storage?

What is the solution to if I use multiple pages and not a singular page and communicate data?

@Assoehosselaar

4 ай бұрын

A database

Where should I put them? Inside a div of course. If only I know how to center them.

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

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?

@philheathslegalteam

4 ай бұрын

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.

I hung my front door key from teh screen door, now someone has taken all my stuff. Don't use doors.

So we have to use AES encryption layer

cookies still not secure look for CSRF :/

Good video! What text editor you are using for the explanation? Is this an online Editor?

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?

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 KZread to auto delete my comment. FKN hell.

This will be great for single page websites but I need to transfer cookie data from one page to another

@redhood7105

4 ай бұрын

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 is... misinformation

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.

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.

Even if this protects against xss what about csrf and even so these solutions are temp as people will find other solutions and methods.

@philheathslegalteam

4 ай бұрын

This does nothing to protect against XSS

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.

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.

@CatMeowMeow

4 ай бұрын

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

@axlYT

4 ай бұрын

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.

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

React cookie components when?

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.

Jesus Fucking Christ, now I understand why react is popular.

Ummm i would love to inform you that cookies aren't safe anymore

Now make video on how we can store data in cookies.....

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?

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.

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

@5omebody

4 ай бұрын

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

@JakeAndDaddy

4 ай бұрын

​@@5omebody no, JWT is secure. it's an encrypted payload.

storing auth token in local storage :))

@philheathslegalteam

4 ай бұрын

Yes it’s common practice not insecure.

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

Server side Javascript was a mistake

wow Josh you deleted my comment because i said i am leaving react world? what's wrong with what i wrote?

@jp0678

4 ай бұрын

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

@Hypergraph

4 ай бұрын

@@jp0678 i hope so, lol:)

@Hypergraph

4 ай бұрын

@@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.

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

@paw565

4 ай бұрын

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.

@joshtriedcoding

4 ай бұрын

"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

@axlYT

4 ай бұрын

@@paw565u can use next-auth library in next js, which automatically sets cookie and also csrf.

@fischi9129

4 ай бұрын

@@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).

@unforgettable31

4 ай бұрын

​@@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?

Who the fuck would ever save sensitive things in localstorage?

@dungledang5120

4 ай бұрын

Him :)) who made this video

Maybe I'm too dumb, but why do you even need a XSS attack if you just can go in the dev tools.

@diegoronkkomaki6858

4 ай бұрын

Dev tools show you your own data, not data of others.

@user-tu7bi3oz4s

4 ай бұрын

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.

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

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.

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

@tvnishq

4 ай бұрын

No s shelock

great video! http only cookies are amazing. which software did you use in the animated diagrams?

Frontend it's not a secure place

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

@itspawanpoudel

4 ай бұрын

It's just a clickbait man

Josh next time chooses any advance topic

LocalStorage is for saving settings such as dark/light mode, keep logged in, accessibility utils, etc

@v01d_r34l1ty

4 ай бұрын

Yeah private data is usually in sessionStorage

@pkgamer7860

4 ай бұрын

​@@v01d_r34l1tySession Storage is the exact same thing man except it's only valid for a session

I started falling asleep exactly when the video stopped with a "boring" screen. So good call to cut it😂

@joshtriedcoding

4 ай бұрын

yeah cant have that here, good to hear the vine boom sound effect woke you up hahaha

You did not demonstrate an actual attack. All things you show is just "imagine" and an "if" scenario that did not happen at all

TLDR: RTFM

inam disappointed by this video because I was really enjoying the content until now

Can you please make a tutorial using Authjs V5, cookie approach, and server actions. Please!!! 😊

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

Mr Josh is a Legend instructor...

props for cutting out the boring part lol

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

@sllide

4 ай бұрын

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.

leaves the door open: - look how houses are insecure

The server could alternately use CSP to prevent access to injection using nonces.

Imagine storing anything sensitive on the client side and getting your PR approved

@jitx2797

4 ай бұрын

How would you persist auth then?

@AndrieMC

4 ай бұрын

yes how? ​@@jitx2797

@Assoehosselaar

4 ай бұрын

@@jitx2797 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.

@philheathslegalteam

4 ай бұрын

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.

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.

don't make a video if there is nothing new. unsubscribed

ah thats a good solution ENCRYPT ALL YOUR DATA

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

@philheathslegalteam

4 ай бұрын

It’s the right tool for this.

You can create a wrapper around local storage which encrypts the value when set and decrypts when done get.

@QwDragon

4 ай бұрын

Useless. Either script can access data or not. And these cases are not interchangable in almost all cases. No any problems with LS.

Google stopped using Cookie. So you should stop using cookie as well lol

This is such incomplete and utterly garbage advice

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

Local storage is only a risk if you are mid.

bullshit. wasted my 5 minutes and 5 seconds because luckily i did'nt watched the remaining video. but please write better title and thumbnail.

indexdb sensitive data. localstorge utility data

Wish the title included a little more context

Impressive, very nice. Let's see Paul Allen's security concerns.

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 🎉 🎉

But then u wanna mess with cookies eu laws🫤

@Lucas-gt8en

4 ай бұрын

The ‘cookies’ law is only about tracking stuff. You don’t need to request permission for basic functionality