Does Storing JWT's In HTTP Only Cookies Stop XSS Attacks

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

[@TheSocialDeveloper]

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!

[@DennisIvy]

Http only cookies can add a layer of protection, but your right, they don’t prevent XSS attacks.

[@DennisIvy]

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

[@TheSocialDeveloper]

@@DennisIvy Very true!

[@abbysands9510]

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.

[@lemek4]

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

[@madvillany420]

Bens hair is like every engineer in my department including mine lol

[@Evkayne]

at leas you have hair XD

[@imgrey2292]

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.

[@alibarznji2000]

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

[@lukeweston1234]

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-hr3xq]

Yup.

[@mursalrabb6093]

but httponly still sounds cooler than local storage so why not?

[@georgesmith9178]

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.

[@tilakmadichettitheappdeveloper]

I LOVE THESE KIND OF CHILL VIDEOS

[@imiebaka]

Just seeing Ben, hitting the like button was automated.

[@bertrandfossung1216]

I just learnt from valuable stuff👍🏽

[@tombalabomba3084]

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.

[@divineer627]

This is worth noting down 🔥🔥🔥

[@achirasilva2567]

Bros doing anything to defent local storage

[@arfan8544]

Two fav people in one video. What else you need?

[@Merserissugoi]

lol that explains in more detail why dogehouse stores jwt in local.

[@shindradavid1309]

☺️ it's like you read my mind, it's just the video I was looking for, guaranteed ♥️

[@daviddoyle7580]

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 ?

[@ryanwhite7887]

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

[@daviddoyle7580]

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

[@adityanr5654]

Worth to watch!! Grabbed some points ✌️✌️

[@rangabharath4253]

awesome. Please make a video on this topic Dennis. It will be very useful.

[@hakuna_matata_hakuna]

wouldn't a cors policy prevent requests for unknown endpoints

[@DennisIvy]

This is why you set allowed origins.

[@7999rahul]

You have to be logged into the app too right? Also why not set really short refresh token time

[@AcademyOmen]

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

[@georgesmith9178]

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-e8622]

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]

In memory as part of the script state... This part im not familiar with. Can you elaborate

[@georgesmith9178]

@@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-hr3xq]

HTTP Only cookies aren't a solution anyway if your API serves mobile and server to server requests too.

[@z-aru]

@@JP-hr3xq I would probably differentiate the API for the browser and mobile

[@otiasammy]

Next time dont rotate the chair! worth watching though

[@Liam.Stevens]

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.