Hello! Welcome to our next lesson on authorization flaws.
In the previous lesson, we learned how to manipulate parameters within visible requests to bypass authorization and impersonate users. We saw how changing a role in a JWT or injecting a user_id via mass assignment could grant us unauthorized access.
Today, we address a different question: What if the most sensitive functionality isn't linked from anywhere in the application? Developers often assume that if a page or API endpoint isn't linked, no one will find it. This "security through obscurity" is a fragile defense. Our goal today is to learn how to systematically shatter it.
This lesson covers the learning outcome: Use forced browsing techniques to access unauthenticated administrative or sensitive endpoints. We will learn how to use automated tools to discover hidden files, directories, and API endpoints that can lead to significant vulnerabilities.
1. What is Forced Browsing?
Forced browsing, also known as content discovery or directory/file brute-forcing, is the process of attempting to access a list of common or predictable file and directory names on a web server. The goal is to find resources that are not meant for public consumption but are still accessible.
These hidden resources often include:
- Administrative panels (
/admin,/dashboard) - Configuration files (
.env,web.config,settings.ini) - Source code repositories (
/.git/,/.svn/) - Backup files (
/backup.zip,index.php.bak) - Undocumented or old API endpoints (
/api/v1,/internal/users)
This is a fundamental technique in penetration testing and bug bounty hunting because it can quickly reveal forgotten or misconfigured parts of an application that are ripe for exploitation.
2. The Anatomy of a Forced Browsing Attack
A successful forced browsing attack has two main components:
- A Fuzzer: A tool that rapidly sends HTTP requests for a list of potential paths.
- A Wordlist: A text file containing thousands of common directory and file names to test.
While many tools exist (Dirsearch, Gobuster, Feroxbuster), one of the most popular and powerful is ffuf (Fuzz Faster U Fool). It's incredibly fast and flexible.
To get a practical sense of how to use ffuf and select the right wordlists, please read the following article.
The article "Content Discovery With FFUF" provides a great introduction to the tool and the importance of choosing the right wordlists. It demonstrates several core commands you'll be using constantly.
Please read the following sections: Introduction and Choosing Tool: Understand why content discovery is important and why ffuf is a popular choice. Choosing Wordlist For Fuzzing: This section is crucial. Pay attention to the different wordlist repositories mentioned, especially SecLists and OneListForAll. Note the strategy of starting with smaller lists before moving to larger ones. FFUF Main Use Cases: Focus on the examples. See how ffuf is used for basic directory fuzzing, recursive scanning (-recursion), adding extensions (-e), and filtering results (-fs).
To help you remember the commands, here is a handy cheat sheet.
3. The Art of Contextual Wordlists
As you just read, the tool is only half the equation. The quality of your wordlist and your strategy for using it are what separate noise from valuable findings. Simply throwing a generic wordlist at every target is inefficient.
How to Directory Brute Force Properly
Professional bug bounty hunter NahamSec provides an excellent overview of how to approach directory brute-forcing with the right mindset. This video will elevate your technique from simple tool-running to a strategic process.
Watch the following segments to learn how to brute-force effectively: What is brute forcing? (00:49 - 01:29): Understand the core objective: finding hidden files and folders that can lead to other vulnerabilities. Wordlist Strategy (02:06 - 02:52): This is a key point. Learn why you must tailor your wordlists to the target's technology stack (e.g., using .aspx wordlists for a Windows server). Contextual Brute Forcing (05:07 - 08:57): Pay close attention to the methodology of using keywords from the subdomain itself to find hidden paths. The example of breaking down one-app.api.company.com into potential path names (one, app, oneapp) is a powerful technique. Personal Methodology (08:57 - 10:11): This summarizes a practical workflow: start with a broad, general wordlist, then refine your search based on the technologies and keywords you discover.
The core takeaway is that context is king. Always analyze your target first:
- What technology is it running? (e.g., PHP, Java, Node.js)
- What does the subdomain name suggest? (
api,dev,staging,admin) - What keywords are relevant to the company or application?
4. Finding Shadow and Zombie APIs
Forced browsing isn't just for finding old admin panels. In modern applications, it's a critical method for uncovering Shadow APIs (endpoints created by developers for internal use or testing that were never documented) and Zombie APIs (old, deprecated versions of APIs that were never shut down). These are prime targets because they often lack the security controls of the main, documented API.
Given your comfort with reading JavaScript, one of the most effective ways to find these is by analyzing the application's client-side code. Developers often leave paths to hidden API endpoints within JS files.
Bug Bounty Recon: Shadow APIs, Zombie Endpoints & How to Find Them?
The video "Bug Bounty Recon: Shadow APIs, Zombie Endpoints & How to Find Them?" by Medusa provides an excellent guide on this topic. It specifically covers how to find endpoints in JavaScript files.
Watch these two key sections: Introduction to Shadow & Zombie APIs (00:00 - 02:33): Understand the definitions and why these forgotten endpoints are so dangerous. Finding Endpoints in JavaScript Files (10:52 - 13:58): This is the most practical part for you. See how you can manually inspect JS files or use tools like Gao and httpx to automate the discovery of hidden API paths that aren't linked anywhere else in the application.
5. From "Not Found" to "Forbidden"
When you are fuzzing for content, you will encounter various HTTP status codes. While 200 OK on a sensitive file like backup.zip is a clear win, a 403 Forbidden response is also a very strong signal. It tells you, "Something exists here, but you're not allowed to see it."
Your job doesn't stop at the 403. It's an invitation to try and bypass the restriction.
Forbidden! Are 403 bypasses worth looking for?
The article "Forbidden! Are 403 bypasses worth looking for?" from Sprocket Security discusses practical techniques for turning a 403 into a successful access control bypass. The code examples will be familiar given your CS background.
Read these sections to learn common bypass techniques: Path Bypass BCheck: Analyze the payload line in the first BCheck code block: payload = "/", "//", "/..;", "/..", "%2f..%2f", .... This shows various path traversal and manipulation tricks used to confuse the server's path-based access rules. Method Bypass BCheck: Look at the methods line in the second code block: methods = "GET", "POST", "PUT", "DELETE", .... This illustrates the technique of trying different HTTP verbs against a forbidden endpoint. Sometimes, an endpoint might block GET /admin but allow POST /admin.
Test your understanding!
You are performing a forced browsing attack against https://api.example.com. Your ffuf scan reveals the following interesting results:
https://api.example.com/v1/users(200 OK)https://api.example.com/v2/users(200 OK)https://api.example.com/v1/admin/(403 Forbidden)https://api.example.com/main.js(200 OK)
What are your next three steps?
Show answer
There are several good approaches, but here's a logical sequence:
-
Analyze
main.js: Given your JS skills, the first step should be to read the contents ofmain.js. Look for any other API paths, especially those containing keywords like "internal", "admin", "debug", or "test". This is often the fastest way to find high-value Shadow APIs. -
Attempt 403 Bypasses on
/v1/admin/: Use the techniques from the Sprocket Security article. Try accessing it with different path variations (/v1/admin/.,/v1/admin/..;/admin/) and different HTTP methods (POST,PUT,HEAD). -
Fuzz for Zombie Endpoints: The presence of
/v1/and/v2/suggests versioning. You could try fuzzing for other versions that might be forgotten but still active, like/v0/,/v3/, or/beta/. Old versions often have weaker security.
Conclusion
You've now learned how to move beyond the visible parts of an application and hunt for hidden treasures. Forced browsing is a blend of art and science, requiring both powerful tools and a strategic, context-aware mindset.
Key Takeaways:
- Forced browsing is an essential technique for discovering unlinked files, directories, and admin panels.
- The effectiveness of forced browsing depends heavily on using contextual wordlists tailored to the target's technology and naming conventions.
- Tools like
ffufare the industry standard for this task, but you must know how to use flags for extensions (-e), recursion (-recursion), and filtering (-fs,-mc). - Always analyze a target's JavaScript files; they are a goldmine for discovering undocumented Shadow and Zombie APIs.
- A
403 Forbiddenresponse is not a dead end. It's a sign that you've found something worth investigating further with bypass techniques.
Next Lesson Preview:
So far in this module, we've focused on bypassing technical controls—improper ID checks, injectable parameters, and hidden endpoints. In the next lesson, we will shift our focus to a different type of flaw. We will learn how to identify and exploit business logic flaws, such as manipulating prices in an e-commerce checkout flow, where the vulnerability lies not in the code itself, but in a faulty assumption about how a user is supposed to behave.