This video shattered my trust in circle-providing npm packages.
@cdruc
8 ай бұрын
🤣🤣🤣🤣
@ruslan_yefimov
8 ай бұрын
We can still use ovals though - just be smarter!
@michaelbitzer7295
8 ай бұрын
Just use squares and cut of the edges, problem solved.
@benjidaniel5595
7 ай бұрын
I mean it must be good if it’s had 1 billy trilly billy downloads
@JakobTheCoder
7 ай бұрын
Thank you for this video. I saw these videos (same topic) so often and never understood why it is so important, but your example with the package is so good.
@Cloneee
8 ай бұрын
It's not about cookies or localStorage, it's about how you handle the validation and protecting methods IN YOUR BACKEND SERVER. When using cookies, there's still XSS, man-in-middle, you can't stop them, just slow them down. The more appropriate way to protect your user is stop using stupid packages from npm and try to use an access token with a refresh token, limit the number of refresh tokens per user, save the user's IP, browser information, and try to use the RTR (refresh token rotation) method.
@moosethemucha
7 ай бұрын
Thank you
@gadgetboyplaysmc
7 ай бұрын
For sessions, you wouldn't really need to take care of refresh and access token, right? A refresh token in itself is like a session already.
@mikooovsky
7 ай бұрын
this refresh token hype is so funny xd
@CristianBilu-q4n
7 ай бұрын
There is another interesting thing that discord does, they store the token in localStorage but: 1. When they load the page the key is deleted from localStorage and loaded in memory 2. When a user leaves the website or closes chrome or the discord app they store it again in localStorage so they can get it on the next load. This mostly works for web applications that don't require opening in new tabs tho, because opening new tabs of your website means it doesn't know the current auth token as it is not in local storage anymore until you close the tab that currently has access to it.
@Dontcaredidntask-q9m
8 ай бұрын
Saying that a httponly cookie is safe and cant be accessed is extremely misleading and dangerous. They can be accessed by XSS and XHR attacks. Setting a cookie to httponly is one part of your multi-layer defense, on its own its not enough, but combined with other layers it helps make your service more secure
@dealloc
8 ай бұрын
Yes but it's easier to mitigate against XSS attacks as you can restrict the cookie through SameSite policy, unlike any JavaScript-accessible storage medium.
@cdruc
8 ай бұрын
I agree; more layers are better, of course. I'm not sure about XSS and XHR attacks being able to access httpOnly cookies, though. I thought the httpOnly attribute was specifically designed to offer protection against XSS/XHR attacks. Can you expand or point to an article/page/docs demonstrating this?
@vagkalosynakis
8 ай бұрын
The httpOnly attribute of a cookie is exactly there to prevent XSS attacks, so you can't access it using that one. I haven't seen XHR attacks and looking online right now, I don't seem to find a way to access an httpOnly cookie as well.
@mibi2509
8 ай бұрын
@@cdruc I never heard of a way to read httpOnly from JS that was not a bug in its implementation. Idk what they are on about.
@dealloc
8 ай бұрын
@@cdruc The problem is not with XSS specifically (accessing the information directly through JS) but that a script can make a fetch from the website's origin and include the credentials (i.e. HttpOnly cookies). If SameSite is not set to either Lax or Strict, it will include those cookies in the XHR request. By default modern browsers will set the SameSite to Lax if it is not explicitly set to None by the website issuing the cookie. So unless you go out of your way to disable it, your users will be safe (also safe against CSRF attacks).
@ouya_expert
8 ай бұрын
I remember being onboarded on a government project that stored JWTs in localstorage which required logging in using your national ID. It was a hell of a shock it got through code reviews and the eyes of every dev who went through it.
@gnorts_mr_alien
8 ай бұрын
yeah I don't agree. if your web app is compromised by a rogue package, it is game over. even if you have a http only cookie, yes, they might not be able to steal the token exactly, but they can still make requests to your backend through the client browser. the cookie will be sent automatically, and they will do what they want to do regardless. they just won't have the token at hand, they'll be able to use it. this is common advice but security theater. with cookies you will have to start to worry about CSRF etc as well. so no method is without its drawbacks. you need to have a threat model. if your threat model is "infected scripts in my site" then neither cookies, nor local storage will save you.
@DaSchTour
7 ай бұрын
An infected script could even load additional javascript that exploits the requests on your page. Do requests to your server and then send the data to another server. If you have untrusted 3rd party scripts on your page nothing will save you. If you do not sanitize user input also anything can happen.
@Sebastian-rn6pb
7 ай бұрын
I knew this was a bad idea from hearing it everywhere, but I never understood how the attacks would work. Thank you so much.
@MichaelScharf
8 ай бұрын
Well, unless you disallow access to any other domain with using Content Security Policy (CSP): For example `Content-Security-Policy: default-src 'self'; connect-src 'self'` there is no way to send data to another domain
@_f0x604
8 ай бұрын
Can CORS prevent sending data to another domain name as well?
@saiv46
8 ай бұрын
@@_f0x604Nope. CORS is about _downloading_ data.
@trapfethen
8 ай бұрын
CSP does not govern browser extensions, nor does it protect from relay attacks. Though, the latter requires you to have a relay vulnerability in your server implementation.
@tigerofdoom
8 ай бұрын
@@_f0x604 No, CORS is aimed at stoping Cross-site Request Forgery, tricking the browser into sending the cookies to perform actions on Website B while the user browses Website A. CSP prevents exactly what's described in the video, exfiltrating data from a site with malicious scripts that are injected into the site (XSS).
@MichaelScharf
8 ай бұрын
@@trapfethen yes, but browser extensions can inject any code and just read you password as you type. When you have a node app, you also have to make sure that the server cannot send data to a malicious sie.
@omnilothar
8 ай бұрын
in devtool you can use breakpoint to tick unload, so when closing tab/window, it will prevent that , so you can check the network after
@vjzb3
8 ай бұрын
Super informative and beautifully demonstrated. Thank you for taking the time to make and share with us!
@MrRiseful
8 ай бұрын
Well wow, malware will simply steal password from login form then
@philheathslegalteam
8 ай бұрын
Exactly. Or just interact with the page on your behalf while serving an absolutely positioned clone of the DOM in front.
@unfilledflag
7 ай бұрын
Gonna be hard to do so when using something like OAuth
@MrRiseful
7 ай бұрын
@@unfilledflag whatever, the spy script will be stealing all data from owner computer, yet won't be able to login from somewhere else
@kanishkc.2762
7 ай бұрын
I hope this goes viral.
@NicJon
8 ай бұрын
Well where should i then store it? Cookies can get stolen the same way??
@davidwang7489
8 ай бұрын
Not HttpOnly cookies. But any malicious JS running on your site can still do a lot of damage. All of these are mitigations.
@atakansenturk563
7 ай бұрын
@@davidwang7489 So what needs to be done?
@bartoszkrawczyk4976
8 ай бұрын
I see so many articles, like "authentication in React" that says to store it in localStorage. Thanks for making this video, I hope it will reach as many people as possible.
@codokit
8 ай бұрын
We need ask react-devs about httpOnly cookies on interviews.
@ieatthighs
8 ай бұрын
this video is very misleading
@whatskookin6429
8 ай бұрын
What you should always do, is read your framework of choice docs. Usually they tell you use local storage is not a good idea.
@bartoszkrawczyk4976
8 ай бұрын
@@whatskookin6429 Absolutely! When it comes to security, never trust some random tutorials or articles.
@daleryanaldover6545
8 ай бұрын
@@ieatthighswhy is it misleading, it provides a valid POC attack tho.
@nugenki
7 ай бұрын
Well done video! The flow on information was really easy for me to follow, with examples and proofs. I will be making this change, and letting others know too, thanks.
@rusty_knife
8 ай бұрын
While not entirely wrong, this video is definitely misleading... By this logic, storing tokens anywhere on the client device is insecure. Now there are definitely limits on both ends, but they really shouldn't be defined by the libraries which are under your control. If this is your concern then I have bad news for you: it's probably not much harder to just steal the credentials while logging in, which is obviously even worse. And that's just the tip of the iceberg probably... The real solution is to vet your libraries properly, which is hard yes, but using a compromised library is dangerous no matter where you store your tokens... Also if you say you should use tokens for mobile apps, then what about compromised libraries in the mobile app? And what about the server, how are you gonna hide things from a malicious library there? All that doesn't mean you shouldn't use cookies for authentication if you can though. There are other benefits to that approach - it is basically what they were made for afterall. It's just that they don't really solve the problem described here...
@Toleich
8 ай бұрын
It's important to remember the fulcrum of security. What are you protecting, and who are you protecting it from? Sometimes it's okay to do "bad practices" because the application doesn't require much security. As long as you are consciously making that choice. You need to know the rules before you break the rules.
@xorlop
8 ай бұрын
I feel like the actual issues here were installing random packages that are not vetted and injection.
@gkiokan
8 ай бұрын
A long time a go for a very long time this was a good practice. You could also bind the token on a specific IP, so you will be still fine. You could also bind the token with a hardware ID and have another validation mechanism on top of the token match. Everything has it's good and bad side. Even considering the Cookie / Session Auth isn't really sure as you can still steal them with proper tools.
@ieatthighs
8 ай бұрын
ITS* good side
@unfilledflag
7 ай бұрын
"bind to ip" now you break the site for any mobile user that joins or leaves a wifi network
@gkiokan
7 ай бұрын
@@unfilledflagthats a good point but still a small edge case. However there are also short lived tokens that could be used with refreshing tokens but this is another hussle and story. So maybe just take the hardware UID to compare if the token is coming from the same device if you really want to make your token a bit more secure.
@ieatthighs
7 ай бұрын
edit out the spelling mistake you made @@gkiokan
@0.lennart
7 ай бұрын
What about static frontends without ssr? There is no way to use a httponly cookie because you have to access it from js
@coldicekiller1352
7 ай бұрын
hash your Auth token with a browser fingerprint and store it, that way you can't spoof it on other computers, there are some libraries that help you do it but its definitely possible with a custom made function.
@gringo5282
7 ай бұрын
Browser fingerprinting is not reliable and there are a lot of collisions (especially in browsers like Safari on iOS). Trusting a fingerprint is also the equivalent of trusting the client, which is pretty well known as a bad idea. If an attacker has a financial incentive to target your site, they can easily write custom code to spoof the fingerprint itself, thus circumventing the check.
@coldicekiller1352
7 ай бұрын
@@gringo5282 yeah, its a game of cat and mouse, availability and confidentiality are opposites in terms of cybersecurity and my solution was mostly done to dether "casual" hackers trying to get a simple oauth spoofing technique paired with a token expiration timer, i guess the real answer depends on the sensibility of your data and how secure you want it to be without affecting the user too much, 2fa auth on every single transaction like some crypto exchanges do it comes to mind, lol.
@Jamiered18
8 ай бұрын
So what you're saying is I can safely keep tokens in local storage... if I just tell users to keep the dev tools open 😉
@Gorlik1337
8 ай бұрын
Cookies and tokens are compromised when you have xss. In both scenarios you are fucked-up. Soo this doesn't add more secureness into your app.
@zManuel
8 ай бұрын
Wrong, httpOnly cookies can't be accessed through javascript
@scrimb
7 ай бұрын
neither cookies nor localstorage tokens will be safe from malicious code in one of your npm packages the actual solution is to limit the amount of npm packages you install, and not load your app with a bunch of random packages with 10 downloads
@fipabrate
8 ай бұрын
Sure, I will use session storage (just kidding). On a serious note, it's worth noting that if you opt for local storage, all tabs end up sharing the same storage space. This means that if you're logged in as a regular user in one tab, and someone else logs in as an admin in another tab, the first tab unexpectedly assumes admin privileges as well. Just something to keep in mind!
@bartwestenenk6088
8 ай бұрын
But your second tab will login as your first user, so the admin can never even login.
@fipabrate
8 ай бұрын
@@bartwestenenk6088 true, but if you logout on second tab and then login as admin
@W4nn3
8 ай бұрын
The same is true for cookies.
@AndersonPEM
7 ай бұрын
Now how do you do if the application is decoupled from the backend? :)
@dhuv
8 ай бұрын
I prefer cookies but you cannot make random requests with javascript to other domains. This is especially easy to lock down with CSP. Even though those libraries read local storage, it is difficult to get that out. Maybe with a browser extension but not likely to happen.
@anmoljhamb9024
8 ай бұрын
DAMN DUDE. The quality of content is just amazing!! an instant sub from me!
@Simple_OG
8 ай бұрын
Ok, i am newbie if not in local storage then where ?
@playwo9635
8 ай бұрын
In a production app yeah sure I agree, but for your average hobby developer not necessarily. Its very easy to mess up or just don't know about CSRF and exploiting a site without a CSRF token is a lot easier than finding an XSS vulnerability in a web app built with any modern frontend framework. Supply chain attacks (or just not being careful and installing random packages) is a real threat and if your app is dealing with actually sensitive data you should invest the time to use a cookie based approach 100% of the time
@AjeshDSthegr8
8 ай бұрын
Reverse psychology works, you just earned a sub
@peteredmonds1712
7 ай бұрын
Supabase stores the `access_token` and `refresh_token` JWTs in local storage. Is there some reason why this is okay?
@kipchickensout
7 ай бұрын
there are third party extensions to show network packages. the one i found was ugly and cumbersome but it worked, and it wasn't detected by the website
@johnmarkvictorino2788
8 ай бұрын
So what the solution for this problem? with Vue as SPA and Laravel API as backend
@Gornius
8 ай бұрын
Server should support storing token in secure, readonly cookie. Client should not have access to them. Server sets token in secure httponly cookie in login endpoint and server reads token from that cookie.
@minimovzEt
8 ай бұрын
@@Gornius that's a load of bullshit, readonly cookies are not secure in any way
@Gornius
8 ай бұрын
@@minimovzEt Yeah, you're right. I meant httponly.
@Bat-Georgi
8 ай бұрын
Ok, so what am I supposed to use instead? Are cookies and session storage any better?
@basarokke4403
8 ай бұрын
Good Topic. But where to store auth Tokens instead of localstorage? Or do you want to say don't use auth tokens? I don't understand your opinion clearly?
@basarokke4403
8 ай бұрын
I want my laravel api in a domain. And my quasar-vue app will consum it. My quasar app is a spa and a cordova app! How to handle this the right way?
@hnccox
8 ай бұрын
store them in a cookie which is httpOnly
@cdruc
8 ай бұрын
If you're using Laravel as a JSON API for a web application, do not use tokens - use the regular cookie based authentication as described here: laravel.com/docs/10.x/sanctum#how-it-works-spa-authentication If you're using Laravel as a JSON api for a mobile app, use token based authentication as described here: laravel.com/docs/10.x/sanctum#mobile-application-authentication If you have both a web app AND a mobile app use.... both. Use the cookie based auth routes for the web app login, and use the token based login routes for your mobile app. ---- I'm not familiar with quasar, but from the looks of it, I think you can just use cookies
@bartoszkrawczyk4976
8 ай бұрын
Just don't manage your tokens with javascript at all. Set it on the server side in a cookie with httpOnly flag. It will be added to every request automatically, it will be handled by your backend, but won't be accessible via javascript.
@basarokke4403
8 ай бұрын
@@bartoszkrawczyk4976 this sounds interesting. Thanks you both! Any resources links where can I see a laravel vue spa example?
@bautistaigarzabal
8 ай бұрын
Hi! right now I have to authenticate my app, and I was thinking about saving the jwt token in the localstorage, but seeing this video I know it's not the right thing to do. The only way I have to use my backend (symfony) is with fetch, I use Axios. How should I do the authentication?
@ieatthighs
8 ай бұрын
If you don't want to go with session cookies localStorage is fine
@bautistaigarzabal
8 ай бұрын
I want to use session cookies, but my frontend and backend are in different docker containers, different ports, and possibly different domains, do you recommend any guide that i can follow to use session cookies?
@ieatthighs
8 ай бұрын
@@bautistaigarzabal I had the exact same situation and I just went with localstorage. It's fine as long as you know the risks. Remember, even discord uses this method
@ieatthighs
7 ай бұрын
@@bautistaigarzabal looks like youtube keeps deleting my responses
@MrCh4nk
7 ай бұрын
@@bautistaigarzabal thats fine, you still can exchange cookies between each service, even though they are in different container, port, domain, zone, just set the cors on the server to allow subdomain/domain where you serve your frontend app to allow credentials, then each of requests fired via axios should have withCredentials set to true and you are good to go
@mmghv
8 ай бұрын
Cookies are more secure but not 100% safe. if you have an XSS, cookies will not help you much if it's a targeted attack, it won't be as easy as blindly stealing auth tokens from the localStorage but an XSS can still do A LOT.
@codokit
8 ай бұрын
XSS can do a lot, but it's another topic about CSRF protection.
@mmghv
8 ай бұрын
@@codokit If you have an XSS, CSRF protection won't matter anymore because attacks will happen from the same site and not "cross-site", the attacker can make the user visit, fill & submit forms that already have CSRF tokens with them, he might even be able to silently craft & send XHR requests with CSRF tokens on behalf of the user, any cookies will also be sent automatically with the requests. in other words, if you have an XSS, you are screwed.
@qbasic16
8 ай бұрын
@@mmghvadd CORS
@priyanshuganatra
8 ай бұрын
0:19 bro predicted the future 😂
@iRoNYwho
8 ай бұрын
so how to handle tokens if you are not laravel developer? Im using session cookie, and take jwt from it. Is it safe?
@cdruc
8 ай бұрын
the cookie must be httpOnly - if it’s not, it’s just as safe as localstorage. what are you using for backend?
@iRoNYwho
8 ай бұрын
@@cdruc golang echo with, jwt and sessions middleware. thx for httpOnly tip, didnt know
@nixjavi7220
7 ай бұрын
great video!
@lightprogrammer
7 ай бұрын
what about sessionStorage?
@rebok232
8 ай бұрын
Doing it on the server's side can be dangerous too, cause if the server automatically reads the cookie to auth you, then what if someone wants to do csrf on you? And also what if your backend is php and you installed a sketchy library, wouldn't it work cause it's server side or what? Solution: Just install trusted libraries
@SirEdges_Adejo
7 ай бұрын
LoL, you just want to comment 😂
@Wariowa345
8 ай бұрын
where am i supposed to do? cookies seems even worst
@muhamedkarajic
8 ай бұрын
Great video!
@jbarriossandrea
8 ай бұрын
Where else should I store my tokens then?😅
@ieatthighs
8 ай бұрын
localStorage is enough
@stephenjayh
7 ай бұрын
Thank you kind sir
@untitled8027
8 ай бұрын
set the secure flag on your session cookies too pls
@arnhazra
8 ай бұрын
Very good explaination. But what if a npm package tracks all the requests that I am sending with body header and everything including response. How to be safe from that ?
@mpcref
8 ай бұрын
use deno instead of node.
@tukangeksperimen7844
8 ай бұрын
@@mpcref why?
@mpcref
8 ай бұрын
@@tukangeksperimen7844to be safe from the concern you're raising.
@kinositajona
7 ай бұрын
Good rule of thumb for beginners. Not going to deny it. But this is irrelevant for any site with even the most simple of Content Security Policies.
@abdhelal
8 ай бұрын
Nice video. I think also using CSP (connect-src ) could save you from some of these problems
@aGj2fiebP3ekso7wQpnd1Lhd
8 ай бұрын
I've often wondered about the security of local storage when using frames as well because the top page and page can use local storage for communication. Will be encrypting data here going forward.
@ieatthighs
8 ай бұрын
encrypting localStorage is pointless
@aGj2fiebP3ekso7wQpnd1Lhd
8 ай бұрын
@@ieatthighs why?
@ieatthighs
8 ай бұрын
@@aGj2fiebP3ekso7wQpnd1Lhd if you intent to keep an access token there it won't prevent an attacker from using it. they just won't know what is inside which is pointless since those tokens are usually random/encoded json of non critical info
@ieatthighs
8 ай бұрын
@@aGj2fiebP3ekso7wQpnd1Lhd I explained but youtube deleted my comment. Thank them
@qbasic16
8 ай бұрын
@@aGj2fiebP3ekso7wQpnd1LhdWhere are you going to store the (symmetric) encryption key? It's pointless.
@陸
7 ай бұрын
Discord be like:Yeah, let's store user token in localstorage!
@lu2000luk
8 ай бұрын
Man, unfortunatley i dont handle auth for my app, my DB does and it stores them in localStorage, and, in some parts of my code extracting tokens from it is actually used. For example to auth the same user across different domains. Thanks for the video btw.
@harryhack91
8 ай бұрын
So you're basically implying that we should go back to a monolith architecture and use Http-only cookies.
@usemt9726
7 ай бұрын
just create a backend that is REALLY safe, the internet is going on a cookieless path, so local storage is not that bad
@BolverBlitz
8 ай бұрын
I like your sarcasm, but you should devently make some warnings for new devs. Like you said, cookies are automaticly within every request. So also in the once made by mallicus code or xss So cookies are even more of a issue than localstorage. The "HTTP Only" Cookie was once an attempt to make it secure, but you just call fetch in js and the browser puts in the cookie anyways... Leaking it. However, you should always use the "Content-Security-Policy" Headers, this makes sure nothing can make requests to any webserver you did not manualy allow first. Then one of the only issues i can think of would be a XSS making a public post on your webpage (in case this is possible) with your secrets, but you can simply check if a post contains a currently valid secret and in case it does just don´t generate the post or invalidate the token like many apps already do it.
@hidvpohaidvhozxcvnpzxov7835
8 ай бұрын
good video
@CitizensCommunity
8 ай бұрын
I love this, so many who think Linux is safe also just trust all their binaries. This is such a problem.
@theblckbird
8 ай бұрын
Awesome!
@Markus-r6g
8 ай бұрын
make sure to tell people how to not store auth tokens, how to know if they already are.
@nefrace
8 ай бұрын
"99% of JS code is not even yours" My website has 0 lines of js code right now and it's all mine
@lucsoft
8 ай бұрын
Sounds like snake oil, if you have XSS then you have already a compromised system. I find local storage more straight forward and I only need to care about XSS not some crazy CSRF or extra security headers.
@nomadshiba
8 ай бұрын
maybe 5% of js is not mine, i write everything
@FabioMafu
7 ай бұрын
I believe most devs write everything
@aleclippe6213
8 ай бұрын
How does this apply to the Microsoft tech stack and azure ad
@gabboman92
8 ай бұрын
that could also happen in apps...
@mauricebagalwa6923
8 ай бұрын
Noted 😎 !
@IIKACHOW95
7 ай бұрын
Guys I think he doesn’t want us to save auth tokens in LocalStorage
@MedChergui
8 ай бұрын
What if i encrypt the token before i store it and decrypt it when i want to use it ?
@qbasic16
8 ай бұрын
And where will you store the key for your (symmetric) encryption?
@MedChergui
8 ай бұрын
@@qbasic16 if i were using SSR this will be at the server.
@qbasic16
8 ай бұрын
@@MedChergui and what's the point on storing an encrypted token on the server? You still have to authenticate the requests from a (valid) client.
@MedChergui
8 ай бұрын
@@qbasic16 The encrypted token will be in localStorage (aka Clinet) but the key to decrypt will be in server. Decrypt it then check if the encrypted token does match.
@MedChergui
8 ай бұрын
@@qbasic16 The encrypted token will be stored in the client, but the key will be in server. The server decrypt the encrypted token and verify the user
@chrismanning5232
8 ай бұрын
The real message of this video should've been to stop using random ass npm packages lol
@OnyxGouws-u2h
8 ай бұрын
Simple, don’t use NPM, there I solved it
@4fortyfour
8 ай бұрын
tell this to discord
@villandoom
8 ай бұрын
Discord be like:
@Mempler
8 ай бұрын
nice, but how the fuck are you store secure tokens in a server-less application. I mean literally, you only get an SPA without any code running on the server other than sending a static file. every single solution will expose the token in an easily accessible way.
@rajikkali2381
8 ай бұрын
No no no. Localstorage is fine. Cookies are no more secure. So tired of hearing this argument on youtube and medium. Even supabase uses this method.
@Andrew-jh2bn
8 ай бұрын
I mean, everything's on a spectrum. Local storage is more vulnerable to compromised JavaScript dependencies then a http only cookie. Of course, depending on how sophisticated the malicious dependency, it could make api calls to your backend while you're visiting the page in your browser, but that would have to be more targeted.
@abdirahmann
8 ай бұрын
yeah me too, am tired of hearing this! 😂😂😂🤡
@michaelbitzer7295
8 ай бұрын
HttpOnly cookies are more secure.
@koushikseal
7 ай бұрын
CSP
@milefiori7694
8 ай бұрын
Why don't encode your auth token then? Even if its stolen it's meaningless to the attacker
@EpKjelltzer
8 ай бұрын
Meaningless in what sense? As long as the token is valid proof of authentication, the attacker will be able to use it to impersonate the user they stole it from.
@ieatthighs
8 ай бұрын
encode? Then the attacker can just decode the token, what are you talking about
@pali122
8 ай бұрын
@@EpKjelltzer But adding the user ip, and browser or extra info should help mitigate those things, plus a refresh token stored on the server. I mean that's the usual JWT pattern. An attacker could decode it but the token should not be valid from anywhere
@RickardBrent
8 ай бұрын
Skip the fluff and get to the point.
@TheNovakon
8 ай бұрын
To build code above malicious packages is very bad idea. Dislike.
@cdruc
8 ай бұрын
huh?
@ZawHlaingWin-ri1js
8 ай бұрын
Are u stupid or smth?
@svendpai
8 ай бұрын
Try giving the video a second watch, it seems like you misunderstood the message of the video.
@DerLuukee
8 ай бұрын
Bot 😅😂
@ieatthighs
8 ай бұрын
oh so it's the self xss argument, as always. If you are already compromised, it doesn't matter where you store your tokens. And the cookies can be stolen using JS too
@AdiktdToLoli
8 ай бұрын
i subscribed anyway... what chu gonna do about it huh >:3
@xajiraqab
8 ай бұрын
document.cookie ? :3
@mehedimi
8 ай бұрын
You can not access HTTP Only Cookie using document.cookie.
@xajiraqab
8 ай бұрын
@@mehedimi if i cant read tokens using js. how can i make refresh token to refresh access token when it expires
@michaelbitzer7295
8 ай бұрын
@@xajiraqabyou simply send a request to the auth server to issue a new token.
@xajiraqab
8 ай бұрын
@@michaelbitzer7295 how if u cant read refresh token
Пікірлер: 207