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

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.

at leas you have hair XD

there's not one layer of security

@@ko-Daegu exactly

Yup.

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.

This is why you set allowed origins.

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.

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.

please add httponly , you will regret it someday