All Nuxt3 routes are displayed in production (Security vulnerability)
Hello! Today I was testing the build of my project for security vulnerabilities and accidentally noticed that if you explore the “Network” tab in the browser on any page of the site, the first chunk that Nuxt3 loads contains code where you can find all the routes that are in my project, even the administrative ones, which, of course, I would like to hide from third-party users.
I researched a few sites that use Nuxt3 to see if others have this problem, and I saw that some sites do (e.g., https://www.ecosia.org/, https://volta.net/), but some do not (e.g., https://www.upwork.com/, https://nba.rakuten.co.jp/).
Could you please tell me if anyone knows about this problem? I would be grateful if you could tell me how to solve it.
P.S. I use SSR in my project, if it matters.
P.S.S. All the sites I showed as an example were found on the Nuxt showcase
16 Replies
This is not a security issue at all.
Be aware that all your frontend code is human readable and available to each user using your website
Finding your routes and more is pretty straightforward from there
In your opinion, the fact that anyone can see what links are on my website (even administrative ones) cannot cause any problems?
(here and example of upwork btw)
as long as your API is properly protected it wouldn't serve data to the unauthenticated users anyway 🙂
Which issues should that cause in your opinion?
(Just to double down, this is the case with any frontend framework 🙂 )
In general, I have a global middleware that checks if the link starts with “admin” and checks authorization and permissions before letting a person access the page and redirects to the login page otherwise (a little more complicated than I described, but you get the idea), but I still think that the less information a potential hacker has, the less likely it is that the site will be hacked
that won't be enough - the data fetched on the admin pages should also come from the API, otherwise one could simply use the debugger and flip booleans around 🙂
still think that the less information a potential hacker has, the less likely it is that the site will be hackedCheck out: * https://en.wikipedia.org/wiki/Security_through_obscurity * https://www.youtube.com/watch?v=gMoipv_NkWE
Security through obscurity
In security engineering, security through obscurity is the practice of concealing the details or mechanisms of a system to enhance its security. This approach relies on the principle of hiding something in plain sight, akin to a magician's sleight of hand or the use of camouflage. It diverges from traditional security methods, such as physical l...
Alexander Lichter
YouTube
window.useNuxtApp - Blessing or Security Issue?
🤔 Debugging Nuxt sites can be tricky, especially when not in dev mode. window.useNuxtApp should help with making that easier.
In this video we will cover everything around the helper:
🧠 Explaining what window.useNuxtApp is doing
✅ Testing it on a live site
🔍 Checking if it is a security issue or not (spoiler: is it NOT)
Links:
🔗 Nuxt PR: https...
Security through obscurity should not be used as the only security feature of a system
When you are using Inertia not all routes are viewable. You can exclude /admin234234 . If you don't use something like Ziggy than you are safe.
Now we are talking about a different kind of application though, where the frontend is no typical SPA 🙂
I also have a global middleware that sends a query to the database whenever the site is navigated, getting information about the user from the backend, and the above check is performed in the middleware immediately afterwards.
I'm sorry to bother you, but I wanted to ask if you think this will be enough for security?
I'm sorry to bother you, but I wanted to ask if you think this will be enough for security?As mentioned, it is important that "protected data" should be served from the API. This is the key to "securing" that data if you have static content which should only be readable for admins, this should also come from your (protected) API and shouldn't be statically embedded in your Vue App
Thank you very much for your advice. I have just been able to enter the administrative interface of the site through an anonymous tab by simply replacing the variable in the debugger 😲.
It turned out like this: a check was performed on the server side, which, when a user tries to log in to the admin without permissions, redirects to the admin login page. And on the login page of the admin panel, there is a check that if the user is authorized, he will be redirected to the main page of the admin panel. As a result, the server side redirects to the login through a 302 redirect, on the login page the server side sees that the person is not authorized, so it allows him to the login page, but on the client side the same middleware (when replacing the variable through the debugger) thinks that the person has permissions and redirects to the main admin page, but since it's a client, the redirect happens not through a 302, but through a regular content substitution by the script, which leads to the possibility of replacing the variable again, avoiding server-side validation.
Sorry to bother you again. Could you please tell me if it is possible to make a 302 redirect on the client side so that the page to which the redirect occurs is processed on the server side?
I solved my problem like this:
if (isUserAdmin && isAdminLoginPage) {
return navigateTo(
/${ADMIN_URL}/, {
redirectCode: 302,
open: {
{ target: '_self'
}
});
}
Now the redirect occurs with a page reload, and the checks are triggered on the server side, not the clientSo you could just avoid the redirect then?
Someone can always work around front end code as I mentioned
^ this is the most important part
thank you!