In a forced browsing attack (also called forceful browsing), an attacker visits URLs containing sensitive information by simply guessing the URL or following a commonly known URL pattern. This attack is made possible by the insecure design of a web application or API.
Forced browsing is formally defined by Mitre in CWE-425. In the latest OWASP Top-10 2021 from the Open Web Application Security Project, forced browsing is not considered a separate cybersecurity category but is included in category A1:2021-Broken Access Control.
Note that forced browsing may seem similar to directory traversal or local file inclusion (LFI) because, in all these cases, a successful attacker can read the content of files on the web server. However, the vulnerabilities that make these attacks possible are very different.
There are several types of business logic vulnerabilities that make forced browsing possible. They are caused by one or more of the following insecure assumptions during application design or coding:
The following are examples of forced browsing attacks made possible by insecure design choices in web applications or APIs.
The developer creates or changes a resource URL that is hard to guess and provides access to sensitive information or privileged functionality. For example, the developer might create an administration interface for the web application at the following URL:
https://www.example.com/superadmin/administerthissite.php
The URL is not linked from any website or application and the developer also makes sure it is not indexed or submitted to search engines. The assumption is that if someone needs admin access, they will get the URL. Nobody else will know it, so nobody else can access it and there is no need for authentication.
There are several ways to perform a forced browsing attack:
This type of vulnerability is common in web applications written by beginners with no security experience, especially for applications meant to be used only within the company Intranet/DMZ. Developers may not bother with authentication since they assume that every user accessing the application has valid access to the internal network and a valid reason to call the URL. Similar issues are also found in APIs, again because developers assume that nobody except a valid caller will know API URLs.
As an example of a typical insecure direct object reference (IDOR) vulnerability scenario, a web application developer might use simple HTTP authentication for the entire application. Once a user is authenticated, they have permission to gain access to any URL on the site. All user resources are accessible via GET requests with numerical IDs as parameters.
The attacker is a user of the site. After logging in, they are redirected to the following web page that contains their legitimate user information and resources:
https://www.example.com/userdata.php?id=2258
The attacker then enters the following URL into the browser address bar, attempting to use a URL parameter representing another (random) user:
https://www.example.com/userdata.php?id=2259
Since the web application does not use user-level authentication but only simple HTTP authentication, the attacker is able to access sensitive data belonging to any other user. They may even try the following ID:
https://www.example.com/userdata.php?id=1
In many cases, ID=1 may belong to an admin user, with that user’s page containing even more valuable information that will enable the attacker to escalate their attack.
This type of vulnerability is common in simple CMS systems where the developer assumes that all users of the CMS will be company employees, especially if access is additionally restricted, for example, to selected IP addresses.
Forced browsing is closely related to other similar web application security issues, such as directory listing. If a web server has directory listing functionality enabled, forced browsing attacks may allow an attacker to access crucial information by using predictable resource locations in the form of common directory names. Here are some examples:
https://www.example.com/source-code/
https://www.example.com/configuration/
https://www.example.com/backup/
This type of attack is common if the web application administrator uses an older version of a web server because older versions of servers, such as Apache, often have directory listing turned on by default. It is also typical for open-source applications, which often use the same, typical resource locations for storing sensitive content.
Forced browsing due to predictable resource locations is also possible without directory listing if the developer uses common files in common directories. For example:
https://www.example.com/config/config.txt
Forced browsing is not a specific type of vulnerability like SQL injection or cross-site scripting (XSS). An application or API may be vulnerable to forced browsing attacks due to a variety of insecure practices associated with authentication.
Forced browsing vulnerabilities are business logic vulnerabilities and, as such, are difficult to detect using automated tools like vulnerability scanners. Automated scanners such as Invicti and Acunetix by Invicti can actively detect exposed backups, configuration files, and other potentially sensitive resources that are present on the server but not linked or otherwise crawlable. However, automated checks cannot indicate whether a resource has been made accessible on purpose or not. Any such results from automated tools, therefore, require manual review to make sure they correspond to actual vulnerabilities.
To prevent forced browsing attacks, developers should never assume that simple solutions are good enough for application data security:
Even less experienced developers can usually avoid these basic errors by using common frameworks for web application and API development. Used correctly, these effectively enforce authentication and access control.
Note that any assumption that a web application firewall (WAF) can temporarily mitigate forced browsing attacks is also incorrect. While a WAF may help to block forced browsing for common directories and file names, it is powerless to prevent directory browsing attacks caused by reliance on security through obscurity or a lack of access control.
Forced browsing attacks happen when URLs or directories on the web server that contain sensitive information have no authentication and/or access control, so an attacker is able to obtain direct access simply by guessing them. The consequences of forced browsing are similar to those of local file inclusion (LFI) – the attacker gains access to the content of sensitive files stored on the web server.
The severity of forced browsing attacks depends on the sensitivity of the information that is accessible without authentication or authorization. In worst-case scenarios, an attacker may obtain administrative access to the web application, its entire source code, or even a dump of the database.
Learn more about secure coding practices that help avoid attacks such as forced browsing.
To prevent forced browsing, use effective authentication and access control for all sensitive resources in your web application or API. Also, make sure that your web server does not have directory listing functionality enabled by default.