Svelte exposing all existing routes in build output

[xriter]

Describe the bug

When building your app, in the generated build files, Svelte is exposing all the existing routes. Even the routes that might be behind auth. Even though the users will not be able to see the contents of a page, it might expose sensitive data that you don't want to be publicly visible.

For example:

 , me = {
    "/admin": [7, [3]],
    "/admin/takeovertheworld": [8, [3]],
    "/admin/ban-all-users": [8, [3]],
    "/(marketing)/shop": [-7, [2]],
    "/(marketing)/shop/unreleased-product-name": [-7, [2]],
    "/api/......": [-7, [2]],
}

It's like having a lock on your door, but providing a thief 🥷 with a detailed floorplan 🗺️ of the house.

I am unable to find a config setting that prevents this behaviour. To me, this makes SvelteKit a no-go to use. Which would be a pity.

Reproduction

Build the app, use Chrome, go to the Web Inspector > Sources > _app/immutable/entry/app.xxxxx.js
At the bottom of this file (in my case) you can see all the exposed urls.

Logs

No response

System Info

-

Severity

blocking all usage of SvelteKit

Additional Information

No response

[elliott-with-the-longest-name-on-github]

This is just how SvelteKit works. FWIW, other frameworks (Next.js included) also do this. I believe Next.js doesn't as of v13, but it still exposes route data in other ways (it's an active area of exploration). It's just required for client-side routing. I believe we've talked about ways to get around this, but we don't have any plans to change it currently.

To me, this makes SvelteKit a no-go to use.

If that's so, it's a shame, but I'm not really sure why -- if you're relying on your route names being "secret" as part of your security plan, you're relying on security through obscurity, and it's going to bite you. Your secure routes should be secure, whether or not users are aware of them.

[xriter]

Thank you for your answer. 🙏

I am aware that other frameworks do this too, and I am surprised that so little people see this as a problem, or at least as a 'minor vulnerability'. (edit: NextJS 13 doesn't do this actually)

If that's so, it's a shame, but I'm not really sure why -- if you're relying on your route names being "secret" as part of your security plan, you're relying on security through obscurity, and it's going to bite you. Your secure routes should be secure, whether or not users are aware of them.

Obscuring routes is of course not 'the solution', but at least a first defence. In any case, serving a detailed floormap on a silver platter is not particularly helping.

So what (reasonable) solutions could there be, if I don't want to expose all existing admin routes that are behind an auth?
Including the admin within the 'main site' is a no-go then.
Putting it on a 'obscure' subdomain is also 'not secure' because people "will eventually find that url also". And as soon as they find a single entry, they find all routes this way as well.

[elliott-with-the-longest-name-on-github]

So what (reasonable) solutions could there be

Not really any that I can think of. There's the unreasonable solution of implementing all of your authed routes as a single catchall route and serving them from handle, but that's ridiculous. Unfortunately, though, this isn't even really a security question -- no one sees it as a "minor vulnerability" because even if users couldn't inspect your routing structure, it would be extremely easy to guess where authed routes are on most sites -- just try /login, /auth, /admin, etc -- a couple dozen guesses at most and you'd be hitting the right subtree. Not to mention, if you link to those routes anywhere (i.e. a login button pointing at /admin), it'd be pretty easy to just crawl them from your site.

The whole point is, any version of "please hide my routes so users don't know what they are" is a security through obscurity argument. It might be nice to have in some cases (routes to feature-flagged content are one that comes to mind), but it breeds a false sense of security. If your site isn't secure to users who know where your routes are, it's not secure to users who don't know where your routes are, either.

[xriter]

I mean, if they were to discover the /admin route, that's fine. They'll just hit an auth wall. However, them being able to see all the existing (but protected) routes behind that auth login is very undesirable. There might be routes exposing sensitive business information (product names, supplier names, employee names, you name it...) which are fine to be exposed to the authorised (internal) users, but not to any visitor of the login wall.

In the search for a solution... Since this is all needed for client side routing, is there a (config setting) way to disable this all together or on a per-route basis? (In the hopes that this will also prevent these routes to be exposed in the buildfile). This being a trade-off of course, but one that might be acceptable to a certain business case.

[AlexRMU]

You can obfuscate your build.
Or next to public routes, create a route with the rest parameters and display the page based on them.
But this is a bad practice.

[AlexRMU]

Duplicate of #5082
Closed by #13379