How to Make Your React App Safer 

I mean, there will always be vulnerability. For example, not only can httpOnly cookies be accessible by the chrome extension api, but if a browser doesn't support httpOnly cookies, then it will treat it like a normal cookie. My point with this wasn't to give a 100% solution, because there isn't one. I just pointed out what you should do to minimize the risk. The risk from using cookies is way less then the risk of using session/local storage.

agree

If only React were only front end code

@nonequivalence1864 Could you please explain how do i make my back end more secure or provide me any blog or channel that you think it might help me I use node.js btw And Thank you ❤

@@AG-ur1lj lmao

pro software engineer ? it’s something new haha

I also saved in localstorage too . but these info from firebase . May be it is safe.

Sorry, but nosense, cookies are same vulnerable to XSS attacks as localStorage, it doesn't matter where you store them, that's why we create tokens so they are encrypted, the only thing you can do is add a little more information in the token. such as the user's browser, device, and checking it on the backend

He have made one before but not with react table. You can find it here: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-HANSMtDy508.html. However I also prefer react table.

@@uttekarlsson3265 implement the same logic with react table

Tbh ive been sick so I haven't been totally up to date with the new release yet! I will try it out and for sure make a vid on my opinions!

@@PedroTechnologies oh god I hope you are doing better ! Thanks for your work my friend

I love India ❤️

@QURASHI AKEEL no one does🗿

Had the same thing on my table today as well, i really hoped there was a solution given here

Nowadays all methods has a vulnerability problem, it's easy to say that save JWT in LocalStorage is dangerous, but nothing is a silver bullet, you just must take a lot of care of your backend, rotating the JWT signature secret regulary and having a system that allows the user to invalidate/ban a stolen JWT based on the identity saved on it

Agreed... Except that you can manually change the input type to text in the developer tools before submitting. So, it is still not safe relying on it completely.

there isn't any foolproof way to store, its kind of anything is vulnerable on frontend and your app security 99% depends on your backend, so make a double check on backend upon token coming from frontend in a req when you are doing some critical action

Redis cache

@@napoleonbonaparte1260 then we have to maintain user session on the server side.

I was left with the same doubt since it does not mention where to store it

What I learned is that it's best to store JWT tokens in cookies, and use them for any API request as it goes on; Make sure to keep the tokens valid for a limited time-span, determined by the nature of the app. After that, revoke access (either directly, indirectly or even both).

you have misundertood 4 things so i'll help you understand them. jwts are not encrypted, they are signed!, both encryption and signing use public private key pairs though, there is a difference between encryption and signing. for example: ENCRYPTION - 1. if i wanted to tell you a secret but there were alot of people that will listen to us, i will ENCRYPT the secret, we will agree beforehand on how to decrypt encrypted data, then i will encrypt the secret and give you the encrypted secret, since we both agreed on how to decrypt data before, you'll be able to decrypt the secret and read it, since all the other people dont know how to decrypt the secret, it will seem to them as a bunch of useless data. SIGNING - 2. on the other hand, if i wanted to announce something to the people and the people wanted to be 100% sure it was me and not an impersonator, i will announce my public key to the people and everyone will have a record of my public key, then i will SIGN the message that i want to announce with my private key, the people then receive my announcement and they will verify the signature in the message that i signed using my public key that i shared with them. 3 .If the jwt is encrypted what can a attacker do with it? - first of all, its not encrypted, its signed as you read above, infact you can go to jwt.io, paste in a jwt that you have and they'll tell you the information contained in the jwt. if an attacker gets hold of a jwt, they can impersonate the person that received that jwt from the backend, the backend only checks to see if the jwt is valid by checking if the signature on the jwt is valid and now that this attacker has a jwt they stole, the backend would allow them to do anything the owner could do and thats BAAAAAD. 4. The attacker also doesn't have the BE details (its in .env file) so the attacker can't use the jwt to update the data in the DB whatever logic you wrote in the app update the data in the db, your users dont update the DB directly, your backend does, and what else does your backend allow?? 🤔, it allows request from the user on the internet 😄, processes the requests and UPDATES the DB to store the information received from the user. you .env file defines what environment your app runs on and what DBs to connect to. The attacker initially doesnt know how your backend is setup BUT they can enumerate your backend by analyzing the response the app returns when they do certain things and hence why the pedro says its better to return a generic statement to the user instead of returning the message of the error which is usually contained in the message field (err.message) i hope this cleared up some confusion and taught you something new, have fun and take care byeeeeeeeeeee

@@abdirahmann great response. I learned a few things in there as far as jwt being signed

@@abdirahmann This comment deserves a pin