I have a web application built in a classic MERN stack (MongoDB, Express, React, Node) and I want to create an admin route, so I figured I could just do it with a [url]/admin route.

Could that be a security risk? Of course the admin users would be prompted with some form of authentication, but having the admin panel as a public route, is that a bad practise?

4 Answers 4


It is not a security flaw to use a known admin URL. The things that should be secret are the management credentials, not the URL. It's like hiding a door, while really it's the key that you should keep secure.

You can protect the door better using human guards, a perimeter fence, extra secure lock, sturdy walls, etc. This should not give you a false sense of security: the lock should still be secure to let only authorized persons enter, but these measures can help.

Translating them to the digital world, you can put the admin panel behind an IP address whitelist (guards that check ID cards), have multi-factor authentication (extra secure lock), only allow connections through an internal management network interface (a fence), etc.

It slightly helps not to have a known/predictable URL, but this is mainly useful for common applications. If there are ten thousand WordPress websites out there and a security issue is found, then the first thing hacking groups do is send hack attempts to as many /wp-admin pages as possible (the standard WordPress admin URL). If you changed your URL to /wp-admin5839 then your site will not be hit in the first wave with untargeted attacks. Nevertheless, if someone means to hack specifically your site, odds are that they spent time guessing your admin page already or managed to figure it out some other way, and once the security issue becomes known, they will just use it on your hidden page before you have a chance to patch. So it doesn't help a lot, but it does help a little in some specific scenario.

  • 4
    On last paragraph: if your door is located in unexpected location that require extra search, robbers will likely go for someone else until they're targeting you. Commented Jan 21, 2020 at 7:53
  • 2
    @valsaysReinstateMonica Better said than I could :). Though it might be good to note that a random robber doesn't care whose stuff they steal (whether it's a TV from you or from your neighbours, it does not matter to them), but with tech companies there is intellectual property to be stolen that cannot be gotten at your proverbial neighbours. So it's more likely that a hacker targets your company than that a robber targets someone in particular.
    – Luc
    Commented Jan 21, 2020 at 9:22
  • While I do agree that secure credentials are important, I think this answer should also mention 0-day exploits. If the software is ever distributed or if it's using an external library/framework for authentication and a bug is found that allows anyone to authenticate, it's easy for a bot to just go to /admin or any other common admin route on any domain and blindly try the exploit. You can protect yourself against that by not having a public admin route to begin with or make it harder for the attacker by having a randomized (and not google indexed) admin route.
    – user185186
    Commented Jan 21, 2020 at 9:42
  • @Morfildur Not sure where the confusion comes from, but that's like half of the answer (the big, fourth paragraph). I did not mention the word 0-day because it applies just as well for n-days.
    – Luc
    Commented Jan 21, 2020 at 15:10
  • 1
    Nice wording on the last paragraph. I like to point to the famous argument about outrunning a bear. In the case of the mass spammed attacks, you're just trying to outrun everyone else. Once a hacker has targeted your site directly, you actually have to outrun the bear themself.
    – Cort Ammon
    Commented Jan 21, 2020 at 17:43

It depends on the use-case of your application. If it's within an organization, you can restrict the admin panel to only respond to requests from a specific source IP. You can also use certificate-based authentication, which is more secure than traditional password-based authentication.

If you write some "general" software, such as Wordpress, you need to be sure that your software is usable for the vast majority of customers, ranging from an individual to a large organization. Therefore, making assumptions about the infrastructure of your customer will be difficult.

In general, it's not really a vulnerability in itself, but it's an unnecessary risk to expose it unless you have to.

  • Even if one writes general software, it should include the ability to restrict access to the admin URL to a whitelist of allowed IPs. With that feature turned on, anyone trying to reach it from a non-whitelisted IP should get a 404, not even admitting of the URL's existence, and not even be asked for login credentials. Commented Jan 21, 2020 at 20:32
  • 1
    @MontyHarder Yes, you can give the option to restrict access, but my point was that it should not be hard-coded to require an IP range to be set from where requests are allowed to originate.
    – user163495
    Commented Jan 22, 2020 at 8:38

Changing the route to the admin page may provide marginal defense against automated bots and script kiddies, since they probably don't have e.g. "/mysupercustomapp-admin/" in their directory wordlist. To me, it seems similar to the concept of changing your SSH port from the default of 22 so that it is missed by automated scans and random brute force attempts.

However, past that, I would almost say it's "security through obscurity" if you are truly relying on a hidden admin page as a protection. Unless it's a very long and hard to type URI path (poor usability), a determined attacker will be able to find it either by automated or manual means.

Instead, you should focus on securing your authentication in general. Enforce proper password strength, consider captchas and/or rate limiting authentication attempts, possibly require client certificates (if appropriate), implement 2FA, limit access to the admin page to trusted/internal IP addresses only, and consider account lockouts or temporary bans (allows for DoS as a trade-off).

TL;DR: There may be benefits to a non-standard admin page path if part of a defense in depth solution, but by no means should it be relied on.

  • 6
    Hiding it via a secret or random URL is just one way of making it non-public, though. Limiting it to internal IP addresses is another way, and is certainly more than just security through obscurity.
    – caw
    Commented Jan 20, 2020 at 15:12
  • @caw Indeed. I can't believe all of the people answering otherwise. How many of these people expose RDP to the Internet on Windows servers, for instance? Commented Jan 21, 2020 at 20:33
  • @MontyHarder true, although I think some of us interpreted it as strictly asking about the URI path. Commented Jan 22, 2020 at 0:24
  • @multithr3at3d I interpreted the word "public" in the question to refer to the accessibility from the public internet vs. from a private network (including VPN). But I can see where you might read "public" as "well-known" (vs security-by-obscurity goofy URI). Commented Jan 23, 2020 at 18:05

Do not put an admin route into your public facing app. The amount of logs I see where hackers have tried to hit the admin URL is unbelievable.

The best option is to have your admin in a second app on an obscure URL and on separate hardware. Protect the admin app with SSL/TLS and use either 2FA or SSL certs for authentication and encryption.

This has the added advantage of simplifying your apps (microservices) and making them more resilient.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .