This argument concerning the dangers of jwt was clearly crafted by an inexperienced software developer and is complete bunk. It is true that jwt has a few drawbacks, but the recommendation to utilize an HTTP session cookie and to keep the session alive in the server creates a much larger number of problems with regard to scalability. Do the research on your own and don't pay attention to what this other person says.
Cookies are different from sessions. Do your research. You can encrypt and store authentication cookies solely in the browser. You don't need server side sessions for that. Also, for scalability, on the server side, sessions are usually stored in redis or database. Never store jwts in the browser. In web applications, whether it's an SPA or not, you should use cookies to securely store authentication state. JWTs are secure for native apps (mobile apps, IOT devices) that can securely store jwts.
He did not create a session on the server. He used http-only cookie in the browser to store the JWT. This way it cannot be accessed and stolen from the JS on the page.
Seems like he doesn't really understand JWT at all. The title says "Stop using JSON Web Tokens" but in reality, he still uses it lol (he just sends it in a different way).
Your approach is better but dev should always to make sure that the length of jwt token is fit enough to be stored as cookie because cookie has limited chars length and not all browser has same cookie space.
You are implying that the drawbacks you mention are the direct cause of using JWT. Those are entirely related to its implementation though. Authentication and authorization done inconsiderate, will be an issue, doesn't matter which technology you use. Seems like you base your knowledge on a specific way it was implemented and you used in the past. Why else would you say, that a JWT shouldn't be stored in a database? Please do your research and don't spread wrong information. You have many followers that might use your channel as reference...
"the drawbacks you mention are the direct cause of using JWT" - Direct or indirect, does it really matter? Or are you implying that it is just a coincidence that so many JWT authentication implementations have major security vulnerabilities. I'd be willing to bet a good chuck of money that localstorage is still the most commonly used place to store JWT-tokens. "don't spread wrong information" - First you need to show that he is in fact wrong.
@@z0n_ it matters. Because it is important to understand the roles of these tools and not confuse it. Especially when you share it in public space. I literally said in my comment, what is wrong about the content. JWT is a standard based on the RFC 7519 spec. The spec proposes a way to share claims between two parties. Encryption and even the signature is optional. What is more important, the spec doesn’t tell you how to do authentication nor authorization. And definitely doesn’t tell you where to store it. It is utterly unrelated.
The biggest problem I have with JWTs is that you can't instantly invalidate them. When your account was hacked you want to change your password and invalidate all existing login session immediately. You don't want a hacker to have access to your account for another 30 minutes because their JWT hasn't expired yet.
you can alway save the last generated JWT for any user, and in case of Hacking or etc. use your saved JWT to compare it with upcoming one to take necessary messures
I think some methods to mitigate this are to watch for IP address and timezone changes. Depending on your risk posture you you can request the user to re-login if certain changes are noticed - but yes that is one of the drawbacks of JWT. Another option is to set the access token to expire ever 5-10 minutes.
But you need to store the token somewhere. - Local storage: Vulnerable to XSS - JavaScript: Logs user out if they press F5 (bad UX). Could be somewhat fixed with refresh-tokens tho. - HTTP Only Cookie: Why even use JWT? Just encrypt your session into the cookie value OR use actual session based authentication (redis etc.).
@@DevGamerBeard Yeah, I can see how that makes sense when you have multiple internal apis and most of them need the access token. But if there is only 1 or 2 internal apis, I find it much easier to just authorize on the BFF. That way you can just store all the information you need into the HTTP Only cookie. Now you don't need to implement token refreshing, just extend the session. It's faster (no db lookup). Only downside is that it does not scale well with many internal apis and is maybe slightly less secure.
Cookie-session is session management, the server needs to maintain a large number of registration records of the client ID to control the client, this is a huge problem, jwt is more like keys and locks, the server does not need to record who has the key, who has the key to unlock, only so simple and reliable, the only security hazard is how to make the client keep the key properly.
@@trunghieulam3623 Would you know if it is possible to send the JWT via an HTTPOnly cookie from a backend which is in a different framework than the frontend? For example, Spring Boot w/ Java backend and React.JS frontend... If the front and back ends are on the same domain, is it possible ? Every example I've ever seen just exposes them in cookie or localstorage
Cookie-Session approach has advantages because yes the server must store all tokens, but you can invalidate them on a user base, something that is impossible with JWT if a token for specific user is compromised.
@@bluex217 You can set the httponly cookie with the response from spring boot. Doesn't matter which front end. I've used this method with spring boot project that served the spa from a reach project within the spring project. Just have to hit the auth endpoint front the front-end and have spring boot set the http only cookie with the jwt when it sends the response back to the client t. From there the browser will include the jwt using the cookie in every request until it expires. That is, if I understand what I was doing lol
Yeah people still use sessions, any serious application will use sessions instead of JWT, in fact if a company does use JWT they will end up having to use sessions along with JWT. You think bank applications are going to use JWT's? Nope, they will use sessions.
Yep, and when you are hosting your stack across multiple kubernetes clusters, then you are doomed. You then have to synchronise your sessions everywhere, it’s no prone to failures. JWT should not be tied to a cookie neither stores. People need to understand what is the concept behind JSON web tokens.
The intent of the message you are trying to get across is great, so I don't want to be too critical, but I have a couple of problems with the video: 'You can always assume you have an XSS' - why, if you use a good UI framework (and there are many of them that are very robust) then this is not a good assumption. Yes, someone who is inexperienced could definitely introduce XSS, but that reinforces the need to use a good UI framework. Either way, understanding XSS, and having a strategy to deal with it is the key. Saying ' storing a JWT in local session is bad because someone can come into your page and steal the JWT through a XSS vulnerability' is like saying 'using a front door key to your house is bad because if you leave your front door open someone can come in a steal your front door key'. If you leave your front door open then probably someone is not interested in your key, they are interested in your house (that's the reason they wanted your key in the first place). More importantly, a XSS vulnerability can potentially allow saving malicious code to the back end, which could affect many more users. If you have an XSS vulnerability then that is a way bigger issue than storing your JWT in local storage.
> 'You can always assume you have an XSS' - why, if you use a good UI framework (and there are many of them that are very robust) then this is not a good assumption. It's a valid assumption though. Never assume you're safe from XSS just because you use a popular UI framework. You rarely just use a single framework. You use a build tool, like Vite, Rollup, Webpack, etc. - you may use plugins for these. Since the build tool changes your code, they may inadvertently inject vulnerabilities into your package. Then there's all the other dependencies. You may use axios, tailwind, moment/luxon, material ui, rxjs, etc. They may depend on other packages. All of which may have undiscovered vulnerabilities, that are copied into your own package. While it is true that having XSS vulnerabilities is a bigger issue than just token storage, the theft of tokens is by far the most critical issue. For hackers to use an XSS vulnerability, they usually have to rely on a user executing their malicious code on the website, i.e. by clicking on links in emails/websites, inserting input data, etc. So doing anything useful, can often require the user to be tricked into doing malicious actions multiple times. But stealing the token, only requires a single user action, then the hackers are able to do whatever they want on their own accord.
@@impero101 Hey there, just for clarity I didn't say I assume I don't have XSS, I just don't 'always' assume I do, which is what my comment related to. Nowadays there are many more potential and likely vulnerabilities than XSS if you are using a mature reputable framework (both in UI and on server - so two layers). So my comment would have been better to say 'you should always assume there is a vulnerability, but now a days XSS is less likely than other vulnerabilities if you are using good frameworks' - aka my comment related to emphasis on 'always assume XSS' in case viewers thought XSS was a greater threat than other types of vulnerabilities. Again its great that people like CoderOne are putting these types of videos out to increase awareness and conversation about cyber issues. NOTE: I re-edited this response because some of my response disappeared when I originally posted it :-(
Thank you for the good video. I saw in the video that you give the option with credential as true(17:40), doesn't that part create a CSRF security threat?
How does adding the JWT to the HTTP-only cookie solve the issue if the request comes from the same origin in the way you demonstrated this XSS? Both localStorage and cookies are only accessible by the domain that created/used them, so if the XSS is succesful both approaches would expose the JWT. What am I missing?
Front-end JavaScript code can't access HTTPOnly cookies, these cookies can be only read by server from the request headers and can only be set by server using response headers.
Also storing jwt in the clear with user ids is a huge risk. Ideally there should be a signed unique token identifier for the jwt and that should be stored as your revocation value.
incorrect, signing is to make sure the payload of the token hasn't been modified. the signature verifies the payload has been created exactly as it is, by the server.
@@danielschmider5069 yes, by "steal" I meant someone else wasn't able to create her own token faking a new session with valid info she read from a valid token in the past. The token would look valid except it won't be signed by the server, so as long as the token didn't disclose sensitive information, it shouldn't matter if it's intercepted and read by third parties.
how the frontend and the server comunicate in production the cookie only use for the same domain can't used between diffrent domains i did the same what you did but it's not working, any suggestion ?
The whole argument why to use http only cookies hinges on the fact that an attacker has gained access to your application through an xss attack and can now execute js code. If that really is the case, you fucked up alreade, because even if the attacker technically cannot gain access to the session-cookie, he can execute api calls on the users behalf from that same origin, which will be authentictated, since the session-cookie will be automatically sent with the request.
Xss doesn’t have to steal the token. Instead, Xss can directly make a malicious request (send money to hacker’s wallet request) if there is an exploitation in client’s code So HttpOnly and LocalStorage both are vulnerable to Xss attack.
With http only cookie, your jwt doesn't risk being stolen and stored on an hacker's server somewhere. Most front-end frameworks have built in xss prevention, that's standard these days. While xss prevention may prevent injected scripts, it can't prevent malicious scripts in your JavaScript or npm packages. That's what http only cookie protects you from.
@@awmy3109 but why hacker need to store short-live jwt on their server?. Instead they just using xss to make directly request behave of exploited users, after getting information they need, they send them back to their server
@@nhanbach1780 Most times when jwts are stored in the browser, they're usually long lived so users won't have to login frequently. XSS is hard. Most front-end frameworks have xss prevention.
@@nhanbach1780 Okay, you store them for 30 minutes and have users login every 30 minutes? How long do yours last? Most implementations have seen, make them last for more hours than usual, sometimes days, to avoid frequent login. Go figure.
Guys I need help. Signing a jwt will prove to the server that it is legit but should I also encrypt it even if it doesn't have sensitive info? Does it provide extra protection?
I agree with the content of the tutorial but the title is miss leading ... anyway I think that JWT token is suitable for applications that used micro services or that needs a load balancer, on these cases JWT will be a necessity. Otherwise where you build a small website or a web application that will be used with few number of users I think JWT is worthless or even a bad practice.
Would you know if it is possible to send the JWT via an HTTPOnly cookie from a backend which is in a different framework than the frontend? For example, Spring Boot w/ Java backend and React.JS frontend... If the front and back ends are on the same domain, is it possible ? Every example I've ever seen just exposes them in cookie or localstorage
Video that the author is not competent enough and does not know that storing credentials in "localStorage" is the worst idea. And the author is not familiar with the techniques of "anti-csrf"
Store session data in a Redis cluster, give user a session id in a cookie then load balance using cookie value. Also, scalability problem is a myth. Even with stateless sessions the very first thing every app does when receives a request it loads something about the user from a storage. It could permissions, user related objects, whenever. You'll be doing tens of queries, why bother reducing this number by one?
@@andreyverbin how do you resolve microservices inter-communication? Pass an Id around? Why we not use symmetric key pattern in JWT? Use the Redis to store user session is ok but too slow.
should you use some form of authentication just for the fact of users accessing the website? Like saving user's IP address and monitor it's requests? If so, what the best implementations or protocols to follow? Can we use JWT for guest users simply browsing the site, a form of passive authentication?
How you are able to see that you store anything with http only... as long as i set this flag true- i cant access them withing the browser =((( the fuuuuck
The attack chain you demonstrated is unrealistic. Storing the token in an HTTP only cookie doesn't stop me from hitting f12 and grabbing it from the application storage. You've only moved the attack vector, not removed it. A better way of combatting token theft would be to use fingerprinting to prevent two different clients from using the same token
XSS is unrealistic? Are you serious? XSS is still top 3 in OWASP top 10 (2021). "HTTP only cookie doesn't stop me from hitting f12 and grabbing it" - Are you trying to imply that in-person attacks are even close to the same severity as remote attacks? If the attacker is already on the users computer your "fingerprinting" won't do shit.
why people think hiding the tokens from an XSS attacker is a smart move. it's like some "bad actors" are already inside your house and you're only worried about the keys. also when using JWT, an XSRF attacker can send the cookie implicitly to the server and the server would not know if it's valid or not and it will send back a response for no reason. I think it would be better to not use a cookie, and use local storage and sign the token. that way the only one is capable of making a valid request is the front-end(in case of web app). and maybe the "bad actors" in your house if you have any. but then you're already checkmated. the only way to protect against XSS is by filtering inputs. JWT has nothing to do with this kinda of bugs.
@@Cognitoman it's not, an xss attacker can do more than accessing your little jwt token form the local storage so not really a bad idea, plus it can be encrypted.
@@anasouardini The only thing good about JWT by the way is scaling because handling sessions can be a pain to set up when you have multiple instances of the same backend running, but if you something like redis for your sessions and point all your backends then can all have access to that. 99.999% of the time it works fine unless you have a huge application.
There's no point in using JWT with sessions. Just store a session id on the cookie an validate that on server side. You are overcomplicating things by using JWT.
no httpOnly flag is set to true to protect for javascript getting access to to the cookie such as; "document.cookie", your thinking of "samesite" flag.
@@oussamasethoum1665 all httpOnly does is make it so javascript on the front end can’t get the cookie , that’s all it does it’s like saying “this cookie is available for request on the headers... so don’t let javascript have access to it”. It basically protects against xxs attacks. For instance if a hacker created a account and made a comment on the website , but that comment he wrote javascript inside a script tag and then saved his comment to the database, then someone like me might login into my account and go to page where he had made that comment the browser would grab his comment out of the database and display to the page, and his comment would javascript in it and it would execute in my Browser. The hackers comment could have script where he says “documents.cookie” , then do a out going request to his website or email or whatever to get that cookie... once he gets it he can login as you because he has it. So... to protect against that happening you put httpOnly=true... when you do that javascript won’t have access to the cookie, then you prevent from getting attacked
![30 ชั่วโมงคนเดียว บนรถไฟชั้น 3 โซเวียต [Around The World Ep. 2]](http://i.ytimg.com/vi/MlE9boAVqDA/mqdefault.jpg)
This argument concerning the dangers of jwt was clearly crafted by an inexperienced software developer and is complete bunk. It is true that jwt has a few drawbacks, but the recommendation to utilize an HTTP session cookie and to keep the session alive in the server creates a much larger number of problems with regard to scalability. Do the research on your own and don't pay attention to what this other person says.
Cookies are different from sessions. Do your research. You can encrypt and store authentication cookies solely in the browser. You don't need server side sessions for that. Also, for scalability, on the server side, sessions are usually stored in redis or database.
Never store jwts in the browser. In web applications, whether it's an SPA or not, you should use cookies to securely store authentication state. JWTs are secure for native apps (mobile apps, IOT devices) that can securely store jwts.
He did not create a session on the server. He used http-only cookie in the browser to store the JWT. This way it cannot be accessed and stolen from the JS on the page.
@@awmy3109 I agree with you except for the part where you've said mobile apps can store JWTs securely
@@awmy3109 ah I see, thanks for clarification
There is nothing to do with JWT.
It’s misleading title of the video.
Better says “Stop using LocalStorage, use HttpOnly Cookies instead”.
Seems like he doesn't really understand JWT at all. The title says "Stop using JSON Web Tokens" but in reality, he still uses it lol (he just sends it in a different way).
that's a reverse psychology title
haha
Your approach is better but dev should always to make sure that the length of jwt token is fit enough to be stored as cookie because cookie has limited chars length and not all browser has same cookie space.
You are implying that the drawbacks you mention are the direct cause of using JWT. Those are entirely related to its implementation though. Authentication and authorization done inconsiderate, will be an issue, doesn't matter which technology you use.
Seems like you base your knowledge on a specific way it was implemented and you used in the past. Why else would you say, that a JWT shouldn't be stored in a database?
Please do your research and don't spread wrong information. You have many followers that might use your channel as reference...
"the drawbacks you mention are the direct cause of using JWT" - Direct or indirect, does it really matter? Or are you implying that it is just a coincidence that so many JWT authentication implementations have major security vulnerabilities. I'd be willing to bet a good chuck of money that localstorage is still the most commonly used place to store JWT-tokens.
"don't spread wrong information" - First you need to show that he is in fact wrong.
@@z0n_ it matters. Because it is important to understand the roles of these tools and not confuse it. Especially when you share it in public space.
I literally said in my comment, what is wrong about the content. JWT is a standard based on the RFC 7519 spec. The spec proposes a way to share claims between two parties. Encryption and even the signature is optional. What is more important, the spec doesn’t tell you how to do authentication nor authorization. And definitely doesn’t tell you where to store it. It is utterly unrelated.
The biggest problem I have with JWTs is that you can't instantly invalidate them. When your account was hacked you want to change your password and invalidate all existing login session immediately. You don't want a hacker to have access to your account for another 30 minutes because their JWT hasn't expired yet.
you can alway save the last generated JWT for any user, and in case of Hacking or etc. use your saved JWT to compare it with upcoming one to take necessary messures
@@nobodyeverybody8437 If you have to hit your database with every request, you just rebuilt sessions.
@@nobodyeverybody8437 if youre doing that might as well use stateful sessions...
I think some methods to mitigate this are to watch for IP address and timezone changes. Depending on your risk posture you you can request the user to re-login if certain changes are noticed - but yes that is one of the drawbacks of JWT. Another option is to set the access token to expire ever 5-10 minutes.
@@sorobby My bank doing something like that apparently, after wifi to mobile data handover my session/token gets invalidated.
Thanks for all the comments below, for you I didn't waste my time
You didn't mitigate the risk of CSRF as well... So the problem is actually not using which authentication mechanism, but how you implement them...
Haha true CSRF can be mitigated through cookies as well, by setting same-site property to strict
JWTs aren’t bad. The vulnerability is XSS here. Once that door is open, the site isn’t yours anymore. An xss can do anything your front end can do.
But you need to store the token somewhere.
- Local storage: Vulnerable to XSS
- JavaScript: Logs user out if they press F5 (bad UX). Could be somewhat fixed with refresh-tokens tho.
- HTTP Only Cookie: Why even use JWT? Just encrypt your session into the cookie value OR use actual session based authentication (redis etc.).
@@DevGamerBeard Yeah, I can see how that makes sense when you have multiple internal apis and most of them need the access token. But if there is only 1 or 2 internal apis, I find it much easier to just authorize on the BFF. That way you can just store all the information you need into the HTTP Only cookie. Now you don't need to implement token refreshing, just extend the session. It's faster (no db lookup). Only downside is that it does not scale well with many internal apis and is maybe slightly less secure.
Cookie-session is session management, the server needs to maintain a large number of registration records of the client ID to control the client, this is a huge problem, jwt is more like keys and locks, the server does not need to record who has the key, who has the key to unlock, only so simple and reliable, the only security hazard is how to make the client keep the key properly.
I usually manage to keep it in Cookie. But it's still JWT travel through the request's header.
You're like the Mongo is webscale guy.
@@trunghieulam3623 Would you know if it is possible to send the JWT via an HTTPOnly cookie from a backend which is in a different framework than the frontend? For example, Spring Boot w/ Java backend and React.JS frontend...
If the front and back ends are on the same domain, is it possible ? Every example I've ever seen just exposes them in cookie or localstorage
Cookie-Session approach has advantages because yes the server must store all tokens, but you can invalidate them on a user base, something that is impossible with JWT if a token for specific user is compromised.
@@bluex217 You can set the httponly cookie with the response from spring boot. Doesn't matter which front end.
I've used this method with spring boot project that served the spa from a reach project within the spring project.
Just have to hit the auth endpoint front the front-end and have spring boot set the http only cookie with the jwt when it sends the response back to the client t. From there the browser will include the jwt using the cookie in every request until it expires. That is, if I understand what I was doing lol
Nobody nowadays create stateful applications that stores sessions, It is against good practices of developing APIs
Yeah people still use sessions, any serious application will use sessions instead of JWT, in fact if a company does use JWT they will end up having to use sessions along with JWT. You think bank applications are going to use JWT's? Nope, they will use sessions.
Yep, and when you are hosting your stack across multiple kubernetes clusters, then you are doomed. You then have to synchronise your sessions everywhere, it’s no prone to failures. JWT should not be tied to a cookie neither stores. People need to understand what is the concept behind JSON web tokens.
The intent of the message you are trying to get across is great, so I don't want to be too critical, but I have a couple of problems with the video:
'You can always assume you have an XSS' - why, if you use a good UI framework (and there are many of them that are very robust) then this is not a good assumption. Yes, someone who is inexperienced could definitely introduce XSS, but that reinforces the need to use a good UI framework. Either way, understanding XSS, and having a strategy to deal with it is the key.
Saying ' storing a JWT in local session is bad because someone can come into your page and steal the JWT through a XSS vulnerability' is like saying 'using a front door key to your house is bad because if you leave your front door open someone can come in a steal your front door key'. If you leave your front door open then probably someone is not interested in your key, they are interested in your house (that's the reason they wanted your key in the first place).
More importantly, a XSS vulnerability can potentially allow saving malicious code to the back end, which could affect many more users. If you have an XSS vulnerability then that is a way bigger issue than storing your JWT in local storage.
> 'You can always assume you have an XSS' - why, if you use a good UI framework (and there are many of them that are very robust) then this is not a good assumption.
It's a valid assumption though. Never assume you're safe from XSS just because you use a popular UI framework. You rarely just use a single framework. You use a build tool, like Vite, Rollup, Webpack, etc. - you may use plugins for these. Since the build tool changes your code, they may inadvertently inject vulnerabilities into your package. Then there's all the other dependencies. You may use axios, tailwind, moment/luxon, material ui, rxjs, etc. They may depend on other packages. All of which may have undiscovered vulnerabilities, that are copied into your own package.
While it is true that having XSS vulnerabilities is a bigger issue than just token storage, the theft of tokens is by far the most critical issue. For hackers to use an XSS vulnerability, they usually have to rely on a user executing their malicious code on the website, i.e. by clicking on links in emails/websites, inserting input data, etc. So doing anything useful, can often require the user to be tricked into doing malicious actions multiple times. But stealing the token, only requires a single user action, then the hackers are able to do whatever they want on their own accord.
@@impero101 Hey there, just for clarity I didn't say I assume I don't have XSS, I just don't 'always' assume I do, which is what my comment related to. Nowadays there are many more potential and likely vulnerabilities than XSS if you are using a mature reputable framework (both in UI and on server - so two layers). So my comment would have been better to say 'you should always assume there is a vulnerability, but now a days XSS is less likely than other vulnerabilities if you are using good frameworks' - aka my comment related to emphasis on 'always assume XSS' in case viewers thought XSS was a greater threat than other types of vulnerabilities. Again its great that people like CoderOne are putting these types of videos out to increase awareness and conversation about cyber issues. NOTE: I re-edited this response because some of my response disappeared when I originally posted it :-(
Thank you for the good video. I saw in the video that you give the option with credential as true(17:40), doesn't that part create a CSRF security threat?
Really dislike seeing a video title shows “stop doing what …” dig a bit more then publish
How does adding the JWT to the HTTP-only cookie solve the issue if the request comes from the same origin in the way you demonstrated this XSS? Both localStorage and cookies are only accessible by the domain that created/used them, so if the XSS is succesful both approaches would expose the JWT. What am I missing?
You can set cookies to be HttpOnly. Javascript cannot read HttpOnly cookies.
Front-end JavaScript code can't access HTTPOnly cookies, these cookies can be only read by server from the request headers and can only be set by server using response headers.
Also storing jwt in the clear with user ids is a huge risk. Ideally there should be a signed unique token identifier for the jwt and that should be stored as your revocation value.
can you please elaborate more, i would love to learn.
How about if the request is cross domain?
signing is to prove the sender didn't steal the token, it doesn't mean it cannot be read by anybody else
incorrect, signing is to make sure the payload of the token hasn't been modified. the signature verifies the payload has been created exactly as it is, by the server.
@@danielschmider5069 yes, by "steal" I meant someone else wasn't able to create her own token faking a new session with valid info she read from a valid token in the past. The token would look valid except it won't be signed by the server, so as long as the token didn't disclose sensitive information, it shouldn't matter if it's intercepted and read by third parties.
still not safe at all against CSRF attack then csrf token should be implemented
how the frontend and the server comunicate in production the cookie only use for the same domain can't used between diffrent domains i did the same what you did but it's not working, any suggestion ?
The whole argument why to use http only cookies hinges on the fact that an attacker has gained access to your application through an xss attack and can now execute js code. If that really is the case, you fucked up alreade, because even if the attacker technically cannot gain access to the session-cookie, he can execute api calls on the users behalf from that same origin, which will be authentictated, since the session-cookie will be automatically sent with the request.
Xss doesn’t have to steal the token.
Instead, Xss can directly make a malicious request (send money to hacker’s wallet request) if there is an exploitation in client’s code
So HttpOnly and LocalStorage both are vulnerable to Xss attack.
With http only cookie, your jwt doesn't risk being stolen and stored on an hacker's server somewhere. Most front-end frameworks have built in xss prevention, that's standard these days. While xss prevention may prevent injected scripts, it can't prevent malicious scripts in your JavaScript or npm packages. That's what http only cookie protects you from.
@@awmy3109 but why hacker need to store short-live jwt on their server?. Instead they just using xss to make directly request behave of exploited users, after getting information they need, they send them back to their server
@@nhanbach1780 Most times when jwts are stored in the browser, they're usually long lived so users won't have to login frequently.
XSS is hard. Most front-end frameworks have xss prevention.
@@awmy3109 “most times jwts are stored in the browser are long lived” ==> where you get that from? From now I know who you are. Done debating
@@nhanbach1780 Okay, you store them for 30 minutes and have users login every 30 minutes? How long do yours last? Most implementations have seen, make them last for more hours than usual, sometimes days, to avoid frequent login. Go figure.
Guys I need help. Signing a jwt will prove to the server that it is legit but should I also encrypt it even if it doesn't have sensitive info? Does it provide extra protection?
I agree with the content of the tutorial but the title is miss leading ...
anyway I think that JWT token is suitable for applications that used micro services or that needs a load balancer, on these cases JWT will be a necessity. Otherwise where you build a small website or a web application that will be used with few number of users I think JWT is worthless or even a bad practice.
Would you know if it is possible to send the JWT via an HTTPOnly cookie from a backend which is in a different framework than the frontend? For example, Spring Boot w/ Java backend and React.JS frontend...
If the front and back ends are on the same domain, is it possible ? Every example I've ever seen just exposes them in cookie or localstorage
@@bluex217 I didn't try using JWT but it should work... It is a cookie and token
just forget the jwt and use server sessions!!!!
Video that the author is not competent enough and does not know that storing credentials in "localStorage" is the worst idea. And the author is not familiar with the techniques of "anti-csrf"
how do you solve the scalability problem by using cookie and server session?
Store session data in a Redis cluster, give user a session id in a cookie then load balance using cookie value. Also, scalability problem is a myth. Even with stateless sessions the very first thing every app does when receives a request it loads something about the user from a storage. It could permissions, user related objects, whenever. You'll be doing tens of queries, why bother reducing this number by one?
@@andreyverbin how do you resolve microservices inter-communication? Pass an Id around? Why we not use symmetric key pattern in JWT? Use the Redis to store user session is ok but too slow.
This is not a true actually.
should you use some form of authentication just for the fact of users accessing the website? Like saving user's IP address and monitor it's requests? If so, what the best implementations or protocols to follow? Can we use JWT for guest users simply browsing the site, a form of passive authentication?
some regulations don't allow to store user's IP
did he just say GeeDoubleYouTea's? lmao wtf
Great video! BTW it's pronounced "jay"WT. If you say "gee"WT it is GWT ;)
CSRF attack unlocked
i can tell u it s better to JS in backend at all not just jwt
What is your VS Code theme?
So if the jwt is bad. Why google, aws.. support oauth2.
How you are able to see that you store anything with http only... as long as i set this flag true- i cant access them withing the browser =((( the fuuuuck
i used a proxy config the react app and it works fine but only in development
can explain bad implementation of refresh tokens
why?
The attack chain you demonstrated is unrealistic. Storing the token in an HTTP only cookie doesn't stop me from hitting f12 and grabbing it from the application storage. You've only moved the attack vector, not removed it. A better way of combatting token theft would be to use fingerprinting to prevent two different clients from using the same token
XSS is unrealistic? Are you serious? XSS is still top 3 in OWASP top 10 (2021).
"HTTP only cookie doesn't stop me from hitting f12 and grabbing it" - Are you trying to imply that in-person attacks are even close to the same severity as remote attacks? If the attacker is already on the users computer your "fingerprinting" won't do shit.
Thanks.
Jwt > cookies. Also not to forget that the W3C is deprecating cookies 🍪
thats to kill 3rd party cookies not samesite cookies
WTF Cookies and JWT are different things. What are you talking about?
why people think hiding the tokens from an XSS attacker is a smart move. it's like some "bad actors" are already inside your house and you're only worried about the keys.
also when using JWT, an XSRF attacker can send the cookie implicitly to the server and the server would not know if it's valid or not and it will send back a response for no reason.
I think it would be better to not use a cookie, and use local storage and sign the token. that way the only one is capable of making a valid request is the front-end(in case of web app). and maybe the "bad actors" in your house if you have any. but then you're already checkmated.
the only way to protect against XSS is by filtering inputs. JWT has nothing to do with this kinda of bugs.
wait what!? store your JWT into local storage? thats a terrible idea.
@@Cognitoman it's not, an xss attacker can do more than accessing your little jwt token form the local storage so not really a bad idea, plus it can be encrypted.
@@anasouardini The only thing good about JWT by the way is scaling because handling sessions can be a pain to set up when you have multiple instances of the same backend running, but if you something like redis for your sessions and point all your backends then can all have access to that. 99.999% of the time it works fine unless you have a huge application.
Plus cookie has a limited size of 4kb, so you can't rely on it
@@mhmdshaaban you should never store sensitive data inside a JWT token because it can be decrypted super easy
I am not convinced.. do more research before making a tech video..
You are now vulnerable to csrf...
There's no point in using JWT with sessions. Just store a session id on the cookie an validate that on server side. You are overcomplicating things by using JWT.
agree
You still want to "sign" your session ID to prove that it's "your" ID. It's not overcomplicating things from that perspective.
Nice
Really great content 👌
Great data, thanks
why would you store a jwt in a localstorage?
JWT it still safe, never ever store any form of valueable data in a local storage
this doesn't make sense even to a junior
clickbait
No.
Intento de developer principiante
Inaccurate. The IEEE has said this is the industry-standard. If you don't use the industry standard, you're the one in the wrong.
Proper SCP helps to avoid XSS.
You mean CSP headers?
Thank you
Awesome
Nice Video
I got one thing its not *jwt so its called *gwt
thats a self xss which isnt that harmfull
LOL!
?!!?!??!
httpOnly cookies works only when you are in the same origin.
no httpOnly flag is set to true to protect for javascript getting access to to the cookie such as; "document.cookie", your thinking of "samesite" flag.
@@Cognitoman Can you set an httpOnly cookie if you are not in the same origin? for example frontend running in a different address that backend.
@@oussamasethoum1665 yeah You can
@@oussamasethoum1665 all httpOnly does is make it so javascript on the front end can’t get the cookie , that’s all it does it’s like saying “this cookie is available for request on the headers... so don’t let javascript have access to it”. It basically protects against xxs attacks. For instance if a hacker created a account and made a comment on the website , but that comment he wrote javascript inside a script tag and then saved his comment to the database, then someone like me might login into my account and go to page where he had made that comment the browser would grab his comment out of the database and display to the page, and his comment would javascript in it and it would execute in my
Browser. The hackers comment could have script where he says “documents.cookie” , then do a out going request to his website or email or whatever to get that cookie... once he gets it he can login as you because he has it. So... to protect against that happening you put httpOnly=true... when you do that javascript won’t have access to the cookie, then you prevent from getting attacked
@@Cognitoman I tried so much to get httpOnly cookie work from different origins, any good article for that or code in nodejs?
Nice tutorial. Can you share with me this project source code?
Source Codes are added to the description
Set cors is a simple and pointed solution. Do think before making videos
Bad developer web tokens is the best
You have zero idea what youre talking about
Another clueless developer.