Admin URLs, hidden pages and security through obscurity
Why renaming the admin address and hiding pages is not protection, what obscurity is good for, and what the real controls are.
The short answer
Renaming the admin login to a secret path, leaving a page unlinked, or hiding an endpoint behind an unguessable name feels like protection and is not. Scanners enumerate common and uncommon paths in minutes, unlinked pages surface through sitemaps, referrers, logs and browser history, and addresses leak through shared links, screenshots and former colleagues. Obscurity has one real benefit: it cuts the noise from automated attacks aimed at default addresses, which makes logs quieter and gives targeted attackers slightly more work. It protects nothing against anyone who actually looks. The real protection for an admin area is authentication with a second factor, access restricted to named people and ideally to known networks, rate limiting on the login, logging of every attempt and change, and, where possible, no public admin at all. A static site whose content is edited through a headless workflow and published by a pipeline has no admin login on the public site to hide, which is the strongest version of the answer.
Obscurity versus control
| Measure | What it actually does | What it does not do |
|---|---|---|
| Renaming the admin path | Reduces automated hits on the default address | Stop anyone who scans, guesses or knows |
| Unlinking a page | Keeps it out of navigation | Keep it out of search engines, logs, history or shared links |
| Unguessable endpoint names | Slows casual discovery | Prevent discovery through responses, scripts or leaks |
| Hiding version numbers | Reduces targeting by known exploits | Fix the vulnerable version |
| Authentication with a second factor | Requires proof of identity to enter | Nothing; this is the control |
| Network restriction | Admin reachable only from known addresses | Nothing; this is a control |
| Rate limiting and logging | Stops guessing; records attempts | Nothing; these are controls |
| No public admin | Removes the target entirely | Nothing; this is the strongest control |
Protecting an admin area properly
- Require a second factor for every admin account, without exception.
- Restrict who has admin access to named people with their own accounts; remove leavers the same day.
- Restrict where from if the platform allows: known networks, a private link, or a gateway with its own login.
- Rate limit and slow login attempts per account and per source.
- Log every login, failed attempt and change, and alert on anomalies.
- Keep the software current, because an admin behind a login is still reachable by an exploit in the login.
- Prefer no public admin: edit through a headless workflow and publish through a pipeline.
- Then, as hygiene, move it off the default path and hide version numbers.
Our take on hidden pages
We do not rely on any page being unfound. If content must be restricted, it sits behind authentication. If it is merely unpublished, it lives in the repository and on preview addresses that require login, not on the public site with no link. And we build business sites so there is no admin login on the public domain at all: content is edited in a workflow, checked in a pipeline and published as files, which leaves attackers with nothing to enumerate.
What this means for you
Treat hidden addresses as hygiene, not protection. Protect admin areas with a second factor, named access, network restriction where possible, rate limits and logging, and keep the software current. Put anything that must be private behind authentication, never behind a missing link. And when you can, remove the public admin entirely by editing through a workflow and publishing static files, which is the one form of hiding that actually works.
Frequently asked questions
We moved our admin login to a secret address. Is that enough?
It reduces the automated noise hitting the old address, which is pleasant. It does not protect the login, because the new address is discoverable by scanning, by reading responses that reference it, by a leaked link, or by a former staff member who knows it. Behind the new address the login must still have a strong password, a second factor, rate limiting and logging. The move is a convenience; those are the controls.
What about pages we do not link to, like a draft or a client-only page?
Unlinked is not private. Search engines find pages through sitemaps, referrers and links from anywhere; scanners guess common names; browser history and analytics record visits; anyone who has the address can share it. If a page must be restricted, it must require authentication. If it merely should not be prominent, unlinking is fine, as long as nothing on it would matter if found.
Is obscurity ever useful?
As a layer, yes. Not advertising the technologies you use, not exposing version numbers, not naming endpoints predictably, and not leaving the admin at the default address all reduce the volume of automated attacks and make targeted attacks slightly slower. Used on top of real controls it is sensible hygiene. Used instead of them it is a false sense of safety.