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!
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
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.
@@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.
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.
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.
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.
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 ?
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
@@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.
@@ryanwhite7887 so the thing is. JWT tokens are not that interesting and you can be fairly liberal with storing and sending them. It's the refresh tokens that are critical in a jwt setup. If you are not going to "rotate/refresh" the refresh tokens, then you want to send them out as little as possible. Http only cookies are not accessible by Javascript. That's good. They are being send automatically with every request tho, according to the security rules you assign to the cookie. Https only (secure flag), samesite (lax allows them to be send to get endpoints, strict only to post endpoints) etc. If you can prevent your refresh tokens from being send too liberally, there might be some attacks you can stop. Http only is just one of the many extra security measures you can take. I have yet to see why this would be hard for developers. So I'll continue to implement them wherever it provides even the tiniest improvement of security.
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.
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
@@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.
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
@@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
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!
Http only cookies can add a layer of protection, but your right, they don’t prevent XSS attacks.
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
@@DennisIvy Very true!
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.
@@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.
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.
Bens hair is like every engineer in my department including mine lol
at leas you have hair XD
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
there's not one layer of security
@@ko-Daegu exactly
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.
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.
but httponly still sounds cooler than local storage so why not?
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.
Yup.
Ben Awad moving constantly reminds me of Kurt Cobain singing Plateau in Unplugged in New York concert
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 ?
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
@@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.
@@ryanwhite7887 so the thing is. JWT tokens are not that interesting and you can be fairly liberal with storing and sending them.
It's the refresh tokens that are critical in a jwt setup.
If you are not going to "rotate/refresh" the refresh tokens, then you want to send them out as little as possible.
Http only cookies are not accessible by Javascript. That's good.
They are being send automatically with every request tho, according to the security rules you assign to the cookie. Https only (secure flag), samesite (lax allows them to be send to get endpoints, strict only to post endpoints) etc.
If you can prevent your refresh tokens from being send too liberally, there might be some attacks you can stop.
Http only is just one of the many extra security measures you can take.
I have yet to see why this would be hard for developers. So I'll continue to implement them wherever it provides even the tiniest improvement of security.
wouldn't a cors policy prevent requests for unknown endpoints
This is why you set allowed origins.
lol that explains in more detail why dogehouse stores jwt in local.
You have to be logged into the app too right? Also why not set really short refresh token time
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.
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
In memory as part of the script state... This part im not familiar with. Can you elaborate
@@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.
HTTP Only cookies aren't a solution anyway if your API serves mobile and server to server requests too.
@@JP-hr3xq I would probably differentiate the API for the browser and mobile
Two fav people in one video. What else you need?
I LOVE THESE KIND OF CHILL VIDEOS
I just learnt from valuable stuff👍🏽
Worth to watch!! Grabbed some points ✌️✌️
This is worth noting down 🔥🔥🔥
☺️ it's like you read my mind, it's just the video I was looking for, guaranteed ♥️
Just seeing Ben, hitting the like button was automated.
awesome. Please make a video on this topic Dennis. It will be very useful.
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
please add httponly , you will regret it someday
Bros doing anything to defent local storage
Ben is relaxing 😆
Next time dont rotate the chair! worth watching though
Please stop spinning on your chair
this guy have no idea what he is talking about
You’re right
@@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
@@ko-Daeguthere’s nothing harsh about sharing ideas and opinions. This is how we get better.