Cybersecurity glossary
What is Forced Browsing?
Learn what forced browsing is, how attackers guess admin panels and hidden URLs without links, how it relates to broken access control, and how to authorize every route—not just hide it.
Definition
Forced Browsing is an attack technique in which adversaries request unlinked or “hidden” URLs, files, and administrative paths directly—relying on guessable names, backups, or wordlists—to reach resources the UI never exposes and that often lack proper access control.
Why forced browsing matters
Hiding a link is not access control. Attackers request /admin, /manage, backup.sql, and .env whether or not any page references them. Forced Browsing is that direct-request technique—and it succeeds whenever authorization is missing on the discovered path.
It commonly surfaces debug endpoint exposure, leftover backups, and panels still using default credentials. The underlying defect is usually broken access control, not clever path guessing alone. Distinct from parameter tampering, the attacker targets whole URLs rather than field values.
How forced browsing works
Build a candidate path list
Wordlists, framework defaults, and leaked maps suggest admin and backup URLs.
Request unlinked locations
Tools hit each path directly without following site navigation.
Observe interesting responses
200s, auth prompts, or partial content reveal real hidden surfaces.
Exploit weak or missing authz
Unprotected admin features, dumps, or debug APIs become the foothold.
High-value hidden targets
Admin and ops consoles
/admin, /dashboard, /console, vendor-specific management paths.
Backup and source artifacts
.git, .bak, .zip, sql dumps left under the web root.
Staging and old apps
Parallel hosts or /old, /v1, /test still wired to real data.
Diagnostic routes
Actuators and profilers discovered without any UI link.
Prevention that works
| Control | Notes |
|---|---|
| Authorize every route | Sensitive handlers check authn/authz regardless of link visibility |
| Remove dead artifacts | No backups, installers, or VCS metadata in publicly served trees |
| Edge deny lists | Block common sensitive filenames and debug prefixes at the proxy |
| Separate admin origins | Management on VPN or SSO-gated hosts, not guessable public paths |
| Content discovery in QA | Run wordlist scans against staging before production |
| Least privilege defaults | Unknown routes 404; never expose directory listings |
- Ensure every admin and internal API route enforces authentication and authorization.
- Purge backups, .git, and dump files from web-accessible storage.
- Place management UIs on isolated networks or SSO-gated hostnames.
- Block high-risk path patterns at the reverse proxy by default.
- Run forced-browsing-style content discovery in pre-prod continuously.
- Verify guessed paths cannot bypass UI-only checks ([broken access control](/glossary/broken-access-control)).
- Watch for [path confusion](/glossary/path-confusion) bypasses of deny rules.
- Never treat an obscure URL as a substitute for real access control.
The practical takeaway
Forced browsing finds what you did not link. Assume attackers will request every predictable path, and protect those resources with real authorization—not obscurity.
If /admin or a backup archive answers without strong auth, fix access control and remove the artifact; renaming the path alone will not save you.
Related security terms
Broken Access Control
Core failure when found URLs lack authorization checks.
Debug Endpoint Exposure
Predictable diagnostic paths frequently discovered by browsing.
Default Credentials
Guessed admin UIs often still accept vendor passwords.
Path Confusion
Parsing tricks that reach resources filters thought were blocked.
Frequently asked questions
What is forced browsing in simple terms?
The attacker types or scripts URLs the site never links to—/admin, /backup.zip, /old/, /config.json—hoping something useful answers without a proper login check.
Is forced browsing a vulnerability or a technique?
It is an attack technique. The vulnerability is usually missing authorization or [security misconfiguration](/glossary/security-misconfiguration) that leaves sensitive paths reachable.
How does it differ from parameter tampering?
[Parameter tampering](/glossary/parameter-tampering) changes values on known requests (price, id, role). Forced browsing discovers or hits entire paths that were never meant to be public entry points.
What do attackers commonly find?
Admin consoles, staging apps, backup archives, `.git` remnants, installers, [debug endpoints](/glossary/debug-endpoint-exposure), and forgotten API versions.
Does “security through obscurity” stop forced browsing?
No. Obscure path names delay casual users only. Wordlists and fingerprinting find them; [broken access control](/glossary/broken-access-control) must deny unauthorized callers.
How do you prevent impact from forced browsing?
Authenticate and authorize every sensitive route, remove dead paths and backups from web roots, deny common sensitive filenames at the edge, and avoid predictable admin URLs as your only control.
Can scanners detect it?
Content discovery scanners and wordlist fuzzers simulate forced browsing. Defense still requires authz on whatever they might find—not relying on “nobody knows the URL.”
References
Explore authoritative guidance and frameworks related to forced browsing.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.