Wow, I really learned a lot from your tutorials about Sveltekit, this is the best and the most valuable learning resources for people who want to quickly dive in Sveltekit application development, I have actually got stuck in authentication for quiet a while because I have no idea how hooks, locals, etc. work and what do they do until your tutorials come out and it save my day, thank you so much 🙏🙏🙏
This is high quality stuff, the kind of errors most people would make and gloss over. Hoping now that sveltekit 1.0 is out, it starts to get some serious industry traction.
Thanks for bringing exposure to this! Since the layout call is cached on continuous redirections it shouldn’t actually be used for auth, but hooks should be, since they’re running on every request as middleware. Still it seems like an easy mistake to be made, so people should definitely be mindful of this case 👏
thb this is a framework issue (I know the Developer needs to know this), but this mistake is too easy to make, a framework should protect you from doing extremly dumb things.
Wow this was awesome! Thank you so much for this! Hopefully you'll do more security / structuring videos! I'll try to support you financially next year because these vids are so valuable for me! Keep it up
1 year later, for some reason cloning the exact same repo#main does not seem to show the behavior. It always runs "Run Layout Auth Check" for the same scenario. Any idea why? Curious as it is running the same sveltekit version (1.0.0)
This video appeared in my recommended loads of times over the past year and I never clicked it, I only remembered now it because I just found out our site has this problem lel
Cool! One odd/wrong question. How would you "protect" some roots in a static page? I know it's impossible to run auth on a CDN or make code not accesible if you know the url but... Knowing the code will be shown, what would you do to make harder the discoverability of new routes. Before anyone ask, yep, I know it's worthless, just wondering.
it's not necessary to make another request just to validate a user, it works but for latency reasons it's easier to work with JWT in an http only cookie as they can be a tool to quickly validate the request as authentic without an extra network request to do the same work
I authenticate and authorize every request using `event.locals` - so even if an user somehow navigates to admin routes, they won't see any data. From my POV authorizing users in `layout.server.ts` in more of an accessibility feature to deny navigating somewhere in the first place.
The real problem here is that the database call isn't passing the auth token along before it pulls data so that the backend ensures your authenticated and have access to the data. That's the real issue, in fact even with the fixes you did, someone could still spoof and call that call to get customers and still get them. Fix that, and everything you showed here is fixed, and then yes you can do the rest of the stuff. But all backend calls for any sensitive data that should be scoped to a role, should pass that data along.
No they couldn’t. The hook is pulling/“validating” the token in this example and went you run await parent it makes a request to the server, thus validating the token/session/whatever.
@@Huntabytestill if it’s really sensitive data don’t just expose it in an api with no validation whatsoever, client side validation is not for security it’s for user convenience. Never trust the client no matter what, all security implementations should be server side.
The main issue here is the server returning data without making any security checks, that's the main issue to be addressed. The server should never return non-public data without checking for a valid token or session. Get that done and all this client side validation becomes purely a UX improvement, as it should be, because you can't force attackers to go through your client side code before making requests to your server.
The example project thankfully demonstrates the correct usage by awaiting the parent in the protected +page.ts routes (I had a GitHub link here directing to the +page.ts in the example repo, but TH-cam didn’t like that 😂) But with that being said, users are still capable of incorrectly setting up the auth by doing what Hunter demonstrated, even with the provided package. If you validate the session in +layout.ts , but don’t await the parent in the child routes, you’ll face this exact issue
Exactly what @Adrian said. The handle wrapper svelteauth provides only sets the session/user into locals, it doesn’t actually protect anything - it’s up to the developer to implement that themselves.
Throwing an error in hooks.server displays default SvelteKit error, I wasn’t able to display error.svelte. The reason is actually simple for example instead of redirecting to login you would like to show 401, 403 or even 404. I guess you can always use page.server to do that, but then your auth logic is splitted a bit
Sir, can you make a tutorial on Sveltekit + Mongodb CRUD/Auth and page/server route protection, I got reading mongodb data working, but I cant find answers about how to create models and perform Create/Update/Delete operations, hopefully you can help people who want to migrate MERN app into Sveltekit 🙏
I thought about this as well. Then I thought: What would happen if I somehow disable/intercept redirects in my browser? Is the redirect the only thing protecting the route? Has anyone info about that?
The redirect is being returned _instead_ of the actual page or usual response. If your browser decides not redirect to the page it's simply going to sit on nothing as no other data has been return from that GET request.
Doesn't this assume that the API is insecure in the first place? I should never be able to access sensitive info without providing my JWT (or whatever mechanism you use). In your example, I could access all your data either way because you API exposes it.
@@HuntabyteThe server shouldn't return any data without a valid session or token, all this client side validation is just for user experience, it adds 0 security.
@@Huntabyte Then your example will fail with a 403 because the token being sent to the server is A) invalid or B) deleted. With Pocketbase, it will invalidate the previous session with a logout. So even asynchronous it will fail because PB's auth checks are synchronous. And if you're implementing something by hand with a mysql socket connection or similar, you should really do the same - e.g. pass a token to a request and verify the token is still good before returning the data.
If you're doing resource access/manipulation without any user checks and it lives close to the client(not a vpc) you're already introducing a lot of security issues into your app. Always make sure the user has permission, for example, what happens if the organization downgrades their access, the idea of a wildcard param thats actually queryable so close to the client will introduce security issues, be it sveltekit, or any framework. Because your basically saying, I'm trusting this small niche feature of a new webapp to always perform as expected through each update
SvelteKit route system is absolutely trashed at this moment. here is critical need one file route system with support of custom route guard\middlewares like it implemented in Laravel or Ember as example.
Thank you very much for this video and explanation of this issue. Do you think the official Supabase GitHub documentation and examples for SvelteKit auth-helpers supabase/auth-helpers/tree/main/packages/sveltekit is incorrect as well?
I don't know about you all, but I'm a for protecting large groups of routes in the handle Hook.
Is that a custom Svelte emoji in a TH-cam comment???!
🤯🤯🤯
@@benaloney one of the perks of being a channel member
:simp:
@@swyxTV 😭
Me too btw great tutorial
Wow, I really learned a lot from your tutorials about Sveltekit, this is the best and the most valuable learning resources for people who want to quickly dive in Sveltekit application development, I have actually got stuck in authentication for quiet a while because I have no idea how hooks, locals, etc. work and what do they do until your tutorials come out and it save my day, thank you so much 🙏🙏🙏
Thank you so much!
This is high quality stuff, the kind of errors most people would make and gloss over. Hoping now that sveltekit 1.0 is out, it starts to get some serious industry traction.
Thanks for bringing exposure to this! Since the layout call is cached on continuous redirections it shouldn’t actually be used for auth, but hooks should be, since they’re running on every request as middleware. Still it seems like an easy mistake to be made, so people should definitely be mindful of this case 👏
You’re welcome! Exactly, or check every page.server load and action.
thb this is a framework issue (I know the Developer needs to know this), but this mistake is too easy to make, a framework should protect you from doing extremly dumb things.
Wow this was awesome! Thank you so much for this! Hopefully you'll do more security / structuring videos!
I'll try to support you financially next year because these vids are so valuable for me! Keep it up
Do not worry about supporting me financially! Just viewing my content and providing feedback is more than enough support!
@@Huntabyte I could only find updated videos on your channel. Can you also do a video on implementing sveltekit auth with directus?
@@thothtrismegistus929 this has been highly requested and is certainly something on my radar to work on very soon!
Dude gonna watch this as soon I am at home
As a svelte user I feel that it’s very interesting
I was making this mistake and being confused by why it wasn't working as I expected. Thanks!!
You're welcome!
Thanks for covering this in a video
You’re very welcome!
MAN, IDK HOW TO THANK YOU ENOUGH
Supabase's SvelteKit starter guide is a security disaster
Is that still the case?
@@lukatoseusno. It uses a combination of hooks, locals and depends to make sure your routes are invalidated.
I had to read the whole github issue comments to understand the supabase implementation.
I was using login check wrongly in layout , thanks for explaining
1 year later, for some reason cloning the exact same repo#main does not seem to show the behavior. It always runs "Run Layout Auth Check" for the same scenario. Any idea why? Curious as it is running the same sveltekit version (1.0.0)
Thank you so much, I was doing exactly the example of the beginning
The problem is that you shouldnt be running these checks on the client anyway.
None of these checks are done on the client in this video :)
This video appeared in my recommended loads of times over the past year and I never clicked it, I only remembered now it because I just found out our site has this problem lel
Thanks Hunter - letting you know the github links are broken, but you can find them in all Repositories...
Whoops! The repo was private!
Cool! One odd/wrong question. How would you "protect" some roots in a static page? I know it's impossible to run auth on a CDN or make code not accesible if you know the url but... Knowing the code will be shown, what would you do to make harder the discoverability of new routes. Before anyone ask, yep, I know it's worthless, just wondering.
it's not necessary to make another request just to validate a user, it works but for latency reasons it's easier to work with JWT in an http only cookie as they can be a tool to quickly validate the request as authentic without an extra network request to do the same work
There are a few different trade-offs with JWTs vs Sessions.
do you think this happens for react router too?
Dang. Didn’t knew this. Thank you!
You’re welcome!
I authenticate and authorize every request using `event.locals` - so even if an user somehow navigates to admin routes, they won't see any data.
From my POV authorizing users in `layout.server.ts` in more of an accessibility feature to deny navigating somewhere in the first place.
Great insight, totally didn't consider this.
What if you copy +layout.server.ts, create +layout.ts and paste the same logic there? Wouldnt that solve the issue?
The real problem here is that the database call isn't passing the auth token along before it pulls data so that the backend ensures your authenticated and have access to the data. That's the real issue, in fact even with the fixes you did, someone could still spoof and call that call to get customers and still get them. Fix that, and everything you showed here is fixed, and then yes you can do the rest of the stuff. But all backend calls for any sensitive data that should be scoped to a role, should pass that data along.
No they couldn’t. The hook is pulling/“validating” the token in this example and went you run await parent it makes a request to the server, thus validating the token/session/whatever.
@@Huntabytestill if it’s really sensitive data don’t just expose it in an api with no validation whatsoever, client side validation is not for security it’s for user convenience. Never trust the client no matter what, all security implementations should be server side.
High value as always!!
Thank you!
Thanks for another great tutorial. Could you please create a video for firebase and sveltekit authentication?
Trying to have the check in root layout.server.js but this causes infinite loop redirect for me 😞 It seems there is no way in SvelteKit to solve this.
there is, use server side hook checks 🙂
Does this apply to server.js API routes?
Yes!
No, +server api routes do not inherit from +layout.server files.
The main issue here is the server returning data without making any security checks, that's the main issue to be addressed. The server should never return non-public data without checking for a valid token or session.
Get that done and all this client side validation becomes purely a UX improvement, as it should be, because you can't force attackers to go through your client side code before making requests to your server.
I have no clue what you're talking about in your comments as there is 0 client-side validation in this video.
did you look at the svelte auth package the vercel guys put out? does that solve things
The example project thankfully demonstrates the correct usage by awaiting the parent in the protected +page.ts routes (I had a GitHub link here directing to the +page.ts in the example repo, but TH-cam didn’t like that 😂)
But with that being said, users are still capable of incorrectly setting up the auth by doing what Hunter demonstrated, even with the provided package. If you validate the session in +layout.ts , but don’t await the parent in the child routes, you’ll face this exact issue
Exactly what @Adrian said. The handle wrapper svelteauth provides only sets the session/user into locals, it doesn’t actually protect anything - it’s up to the developer to implement that themselves.
nice vid, what about throwing errors from hooks.server? Are we able to display +error.svelte page?
I actually don’t think I’ve had a reason to try that! Let me know if it works for you!
Throwing an error in hooks.server displays default SvelteKit error, I wasn’t able to display error.svelte. The reason is actually simple for example instead of redirecting to login you would like to show 401, 403 or even 404. I guess you can always use page.server to do that, but then your auth logic is splitted a bit
Thanks for this video, was making this mistake
You’re very welcome!
Sir, can you make a tutorial on Sveltekit + Mongodb CRUD/Auth and page/server route protection, I got reading mongodb data working, but I cant find answers about how to create models and perform Create/Update/Delete operations, hopefully you can help people who want to migrate MERN app into Sveltekit 🙏
I will certainly look into this, thanks a ton for the suggestion!
I thought about this as well. Then I thought: What would happen if I somehow disable/intercept redirects in my browser? Is the redirect the only thing protecting the route? Has anyone info about that?
I actually haven’t. You could also throw an error to render out an error page in place!
The redirect is being returned _instead_ of the actual page or usual response. If your browser decides not redirect to the page it's simply going to sit on nothing as no other data has been return from that GET request.
What browser are you using there?
Microsoft Edge
@@Huntabyte Cool, thanks.
I like those side tabs, looks compact, never knew Edge had that kind of feature.
TLDR Protected requests happens anyway when using Layout...
Doesn't this assume that the API is insecure in the first place? I should never be able to access sensitive info without providing my JWT (or whatever mechanism you use). In your example, I could access all your data either way because you API exposes it.
The API is an example. Pretend the API is a direct connection to a DB and the SvelteKit server is acting as our Authorization/authentication server
@@HuntabyteThe server shouldn't return any data without a valid session or token, all this client side validation is just for user experience, it adds 0 security.
@@ricardoamendoeira3800 it’s not client side validation. It’s validation in the server load function.
@@Huntabyte Then your example will fail with a 403 because the token being sent to the server is A) invalid or B) deleted. With Pocketbase, it will invalidate the previous session with a logout. So even asynchronous it will fail because PB's auth checks are synchronous. And if you're implementing something by hand with a mysql socket connection or similar, you should really do the same - e.g. pass a token to a request and verify the token is still good before returning the data.
Hahahaha nice :)
If you're doing resource access/manipulation without any user checks and it lives close to the client(not a vpc) you're already introducing a lot of security issues into your app. Always make sure the user has permission, for example, what happens if the organization downgrades their access, the idea of a wildcard param thats actually queryable so close to the client will introduce security issues, be it sveltekit, or any framework. Because your basically saying, I'm trusting this small niche feature of a new webapp to always perform as expected through each update
Surreldb with sveltekit tutorial..
great video
Glad you enjoyed it
I'm in this video, and I don't like it :D
😂
SvelteKit route system is absolutely trashed at this moment. here is critical need one file route system with support of custom route guard\middlewares like it implemented in Laravel or Ember as example.
Never compare sveltekit with php again
Thank you very much for this video and explanation of this issue.
Do you think the official Supabase GitHub documentation and examples for SvelteKit auth-helpers supabase/auth-helpers/tree/main/packages/sveltekit is incorrect as well?