LocalStorage, Cookies or HTTP Only Cookies? Where should we store JSON Web Tokens? Asking @bawad Check out my full stream with Ben Here: • Startups, Cookies, and...
Пікірлер: 52
@TheSocialDeveloper3 жыл бұрын
HTTP only cookies protect you from XSS, but what you’re talking about is CSRF (Cross Site Request Forgery). CSRF is the instance of them taking the token. In summary, no http only cookies don’t secure the application, but it adds layers which is what you’re suppose to do to make it harder for malicious users!! Also, great stream!
@DennisIvy3 жыл бұрын
Http only cookies can add a layer of protection, but your right, they don’t prevent XSS attacks.
@DennisIvy3 жыл бұрын
My final consensus after taking with a Bunch of developers is that there are other areas you should focus on. As Ben said, if you do things right, using local storage is just fine
@TheSocialDeveloper3 жыл бұрын
@@DennisIvy Very true!
@abbysands95103 жыл бұрын
Interesting, speaking of security what do you think of the way Django allows users to upload files. I have been using Flask for a couple of years but recently I started learning Django and I am amazed by the power of Django from the Admin dashboard to other features it has. One thing Flask has that I cannot seem to find the equivalent in Django is the way it allows users to upload files. Basically, Flask has a module called 'secure_filename' and long story short what it does is it takes the file uploaded by the user and returns a more secure filename path that has been filtered so that a nefarious user cannot cause damage. This secure file path can then be used to upload your files I read the Django documentation and it seems PIllow handles most of the security for the ImageField but Django documentation also mentioned not to trust users with uploading files and that certain things might get through. Now, if you uploading the files yourself there is no cause for concern but if you building something that allows users to upload that might be a problem.
@lemek42 жыл бұрын
@@TheSocialDeveloper @Dennis Ivy I would call it partially true. In some rare occasions, you're not "the only one in control". And by that I mean, malicious or not secure third party library, or even resources like ads or analytics, not mentioning browser addons ;) The less you can do from JS layer the better. Unless you have good reason to use browser storage api, you should stick to solid httpOnly cookie. It's not rly hard to implement, and gives a layer of security.
@madvillany4203 жыл бұрын
Bens hair is like every engineer in my department including mine lol
@Evkayne3 жыл бұрын
at leas you have hair XD
@imgrey22922 ай бұрын
I'm currently learning cookie and header, and have almost grasp the idea. I'm just glad to hear the topic shared to the world, it's just feels great to listen as a beginner or probably even the experts I believed in web development.
@alibarznji20002 жыл бұрын
I am exactly like Ben, I flip flop between the storages a lot, but I always wonder why is there no absolute secure way of doing authentication
@ko-Daegu Жыл бұрын
there's not one layer of security
@alibarznji2000 Жыл бұрын
@@ko-Daegu exactly
@lukeweston12342 жыл бұрын
This is reassuring. Honestly implementing auth has gotten me to the point where if I need it again I will just use some auth service.
@JP-hr3xq2 ай бұрын
Yup.
@mursalrabb60933 жыл бұрын
but httponly still sounds cooler than local storage so why not?
@georgesmith917810 ай бұрын
If you cannot get the access token from an http only cookie, you cannot get the Resource Server to authorize your request, but you can send the http only cookie, which is in a way equivalent to provideing your refresh token, if it is stoed in it. I don't think you can access the memory space of an executing script, though - only the space of your malicious script, if you are a hacker. So, I think this leaves only the storing a JWT refresh or access token in memory as the only secure option.
@tilakmadichettitheappdeveloper3 жыл бұрын
I LOVE THESE KIND OF CHILL VIDEOS
@imiebaka2 жыл бұрын
Just seeing Ben, hitting the like button was automated.
@bertrandfossung12163 жыл бұрын
I just learnt from valuable stuff👍🏽
@tombalabomba30844 ай бұрын
While it is true, that an xss attacker has access to make api calls on the victims behalf regardless of auth with http-only session-cookies or token based auth, the scope, duration and context of the attack is always confined to the clients session when using auth with cookies, while the theft of auth-tokens and refesh-tokens, can result in unlimited access for the attacker, unbeknownst to the victim.
@divineer6273 жыл бұрын
This is worth noting down 🔥🔥🔥
@achirasilva25674 ай бұрын
Bros doing anything to defent local storage
@arfan85443 жыл бұрын
Two fav people in one video. What else you need?
@Merserissugoi3 жыл бұрын
lol that explains in more detail why dogehouse stores jwt in local.
@shindradavid13093 жыл бұрын
☺️ it's like you read my mind, it's just the video I was looking for, guaranteed ♥️
@daviddoyle75802 ай бұрын
If you store your access tokens in http only cookies then are you even able to send them In the bearer header to you backend APIs ?? That's what I thought the issue was and why ppl opt for local storage or non http only cookies ?
@ryanwhite78872 ай бұрын
This is the rabbit hole I’m also going through! Do I just store the JWT in local storage or attempt implementing http only cookie? I believe http only cookie can only be read and set by the server for the client. The client cannot read the cookie using javascript. How do I send the cookie with the request? Yet to find a simple video showing the implementation. For practical purposes, I believe I’m leaning towards storing in local storage, and using 2FA for anything important. At the end of the day, I’m not a bank or insurance company with vital user info, I’m just trying to persist the signed in state in a simple method
@daviddoyle75802 ай бұрын
@@ryanwhite7887 I ve been reading about it all weekend lol and it seems that the http only is just automatically sent with every api request so you dont have to explicitly send it like you would in the bearer header with the client side non http only cookies. The problem is if youre using an AWS library Amplify which only works client side!!! So you cant make http only cookies with this aws library.
@adityanr56543 жыл бұрын
Worth to watch!! Grabbed some points ✌️✌️
@rangabharath42533 жыл бұрын
awesome. Please make a video on this topic Dennis. It will be very useful.
@hakuna_matata_hakuna5 ай бұрын
wouldn't a cors policy prevent requests for unknown endpoints
@DennisIvy5 ай бұрын
This is why you set allowed origins.
@7999rahul11 ай бұрын
You have to be logged into the app too right? Also why not set really short refresh token time
@AcademyOmen3 жыл бұрын
Ben is relaxing 😆
@otis3744 Жыл бұрын
thank you because httponly tokens can be a nightmare, so you’re right, security for intense stuff must be shifted over to the user rather than relying on a token to validate someone’s identity
@pylvr8021 Жыл бұрын
please add httponly , you will regret it someday
@georgesmith917810 ай бұрын
No Ben, it is NOT what is easiest for the developer. It is about what is the most secure way to do it. And it seems there are only two options: in memory as part of the script's state (most secure) and as an HTTP Only cookie (with the browser blocking JavaScript from reading the contents of the cookie). But something tells me that if it is a cookie, albeit HTTP only, it is still stored somewhere on disk and therefore is susceptible to other types of attacks that can retrieve and arbitrary file.
@paul-e862210 ай бұрын
in memory is hard as your session only lives in the browser tab that's active, page refresh also kills the session which is why not many store it in memory unless you're a bank. Http only is fine but as they said pros and cons
@googoochu39239 ай бұрын
In memory as part of the script state... This part im not familiar with. Can you elaborate
@georgesmith91789 ай бұрын
@@googoochu3923 Every JavaScript that executes in the browser has its own memory space. As such, it is not accessible to other scripts. Ergo, if you store you token in a local script variable, it will only be available to that script. An httpOnly cookie is not readable via JavaScript, but you can still highjack the cookie itself and send it to server. If it contains a refresh token, which many people tend to store there, you can get back a valid access token.
@JP-hr3xq2 ай бұрын
HTTP Only cookies aren't a solution anyway if your API serves mobile and server to server requests too.
@z-aru16 күн бұрын
@@JP-hr3xq I would probably differentiate the API for the browser and mobile
@otiasammy3 ай бұрын
Next time dont rotate the chair! worth watching though
@Liam.Stevens3 жыл бұрын
Please stop spinning on your chair
@pylvr8021 Жыл бұрын
this guy have no idea what he is talking about
@DennisIvy Жыл бұрын
You’re right
@ko-Daegu Жыл бұрын
@@DennisIvy not trying to be so harsh but talking about JWT and not saying the basics: - HTTPs + Set Short Expiration Time + Renew Tokens with Refresh Tokens + Use Secure, HttpOnly, and SameSite Attributes + Implement CSRF Protection: + Encofing sensitive data now when it comes to storing it it's not either A or B there are other solutions could have been talked about as well: - IndexedDB - using 3rd party solution (or implement your own not in this case clearly lack of experience here) Amazon Cognito, Keycloak, Okta
@DennisIvy Жыл бұрын
@@ko-Daeguthere’s nothing harsh about sharing ideas and opinions. This is how we get better.