Home / Knowledge hub / Forced browsing
Knowledge hub
Forced browsing
Typing the address of a page you were never linked to and finding it opens.
What it means
Forced browsing is requesting a page, file or endpoint that the app never links to for you, and finding that the server serves it anyway. The attacker guesses or discovers the address, such as /admin, /backup.zip or /reports/2024-all.csv, and simply asks for it.
It rests on a wrong assumption: that a page nobody links to is private. A web server answers a request, whether or not a link exists. If the page has no access check, the lack of a link is the only thing protecting it.
Why it matters
What is found this way is often valuable: admin panels, exports, backups, old versions of the app, configuration files, logs and test pages. Any of these can carry customer data or secrets, and a leaked config file may hand over database passwords.
It is simple to do, and tools do it by the million with word lists. Anything that is reachable on the internet will be tried quickly. A "hidden" path is not a control, only a delay. Treat every public address as already known.
How it shows up
You meet it in pages added for staff, in files left in the web root after a release, in old API versions, and in upload or export folders where files have predictable names. Source control folders, build output and editor backups also turn up this way.
To check, run a crawl plus a word-list scan against the running app, and compare what is found with what you intended to publish. Fixes: require authentication and authorisation on every page that is not public, keep non-public files out of the web root, and remove old versions. Do not rely on obscure names.
Questions people ask
Forced browsing, answered
Is forced browsing the same as directory brute forcing?
Directory brute forcing is a way of doing it: trying many names from a list. Forced browsing is the wider idea of asking for pages you were not shown.
Does a robots.txt file protect hidden pages?
No. It asks well-behaved crawlers to stay away and it lists the very paths you want hidden. Treat it as a public hint, not a lock.
Is it only about admin pages?
No. Backups, exports, logs, old APIs, test pages and source folders all show up. Anything the server will return without a check counts.
How does it relate to broken access control?
It is one way to find broken access control. The page exists and the server serves it, but nobody checked whether the visitor should see it.
How do we test for it?
Run a word-list scan against production and staging, review the results by hand, and try each found page with no session and with an ordinary account.
Sources
Where this comes from
Related
Terms that sit next to this one
Broken access control
An application failing to enforce its own rules about who may do what.
Enumeration
Working out what exists by asking repeatedly and watching the answers.
Admin panel exposure
A management page left reachable by the public or by ordinary accounts.
Unauthenticated access
Anything your application answers without signing in at all.
Missing function-level access control
A sensitive action that checks you are signed in but not whether you may use it.
What is on your server, not your menu?
We look for pages, files and endpoints that answer without a check and report the ones we opened, with the request and response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.