Bug bounty hunting is an exciting way to uncover security flaws in websites and earn rewards by reporting them ethically. One of the best places to start is by finding sensitive endpoints — URLs or paths on a website that might expose sensitive data, misconfigurations, or exploitable vulnerabilities like open redirects or authentication bypasses. Subdomains, such as dev.example.com or api.example.com, often host these endpoints due to weaker security in development or staging environments. To help you hunt effectively, this article provides a powerful wordlist of sensitive endpoints and clear commands to use it with popular tools. Whether you're a beginner or a seasoned hunter, this guide will show you how to scan subdomains for "fishy" endpoints like service-worker.js or exposed APIs. Let’s dive in!

Why Hunt for Sensitive Endpoints?

Sensitive endpoints are paths like /config.json, /admin, or /api/v1/users that may reveal sensitive information (e.g., API keys, user data) or enable attacks (e.g., account takeovers via OAuth misconfigurations). Subdomains are prime targets because they often host less-secured systems, such as test environments or legacy apps. A well-crafted wordlist, combined with tools like gobuster or ffuf, can help you systematically discover these endpoints and uncover vulnerabilities worth reporting to bug bounty programs on platforms like HackerOne or Bugcrowd.

The Sensitive Endpoint Wordlist

Below is a carefully curated wordlist designed for bug bounty hunters. It includes common sensitive endpoints like configuration files, API paths, admin panels, backups, and redirect-related endpoints (e.g., service-worker.js), inspired by real-world vulnerabilities like the GitLab OAuth bypass case.

# Sensitive Endpoints Wordlist for Bug Bounty Hunting
# Includes configuration files, API endpoints, admin panels, backups, cloud resources, and more
# Use with tools like gobuster, ffuf, or dirsearch on subdomains
# Inspired by common vulnerabilities and real-world cases (e.g., service-worker.js)

# Configuration Files
config
config.json
settings
settings.json
.env
.env.local
.env.dev
.env.prod
config.xml
settings.xml
web.config
app.config
config.ini
wp-config.php
configuration
configuration.json
config.yaml
config.yml
.env.bak
.env.example# Service Worker and JavaScript Files
service-worker.js
sw.js
worker.js
manifest.json
app.js
main.js
bundle.js
scripts.js
config.js
init.js
serviceworker.js# API Endpoints
api
api/v1
api/v2
api/v3
rest
rest/v1
graphql
api/config
api/settings
api/users
api/admin
api/auth
api/keys
api/token
api/v1/config
api/v1/users
api/v1/admin
rest/admin
rest/config
graphql/admin
api/debug
api/status
api/health# Admin and Debug Panels
admin
admin.php
admin.html
admin/
dashboard
dashboard.php
controlpanel
cpanel
admin-panel
admin/login
admin/auth
debug
debug.php
debug/
metrics
METRICS
actuator
actuator/health
actuator/env
admin/config
admin/settings
dashboard/admin
debug/info
trace
TRACE# Backup and Exposed Files
backup
backup.zip
backup.tar.gz
backup.sql
db.sql
database.sql
site.bak
backup.bak
data.zip
archive.tar
backup.gz
site.sql
db.bak
backup/
backups/
data/
archive/# Cloud Resources and Storage
storage
files
s3
bucket
storage/
files/
s3.amazonaws.com
s3/
storage/files
uploads
uploads/
public/
assets/# Authentication and OAuth Endpoints
oauth
oauth/authorize
auth
login
signup
register
password
reset
forgot-password
auth/token
oauth/callback
auth/login
auth/register
auth/reset
oauth/v1
oauth2
oauth2/authorize# Miscellaneous Sensitive Endpoints
phpinfo.php
info.php
test
test.php
dev
dev/
staging
staging/
internal
internal/
private
private/
.git
.git/config
.htaccess
robots.txt
sitemap.xml
crossdomain.xml
clientaccesspolicy.xml
server-status
status
health
env
version
changelog
readme
README
README.md
changelog.txt
swagger
swagger.json
swagger.yaml
openapi.json
openapi.yaml
logs
log
access.log
error.log
logs/# Redirect and Notification Endpoints
redirect
redirect/
callback
webhook
webhooks
webhook/
notify
notification
push
redirect.php
callback/
webhooks/# Case-Sensitive Variations (Inspired by real-world cases like inDrive)
ADMIN
CONFIG
DEBUG
METRICS
STATUS
HEALTH
API
REST
GRAPHQL
BACKUP
STORAGE
FILES# Common File Extensions for Sensitive Files
.bak
.zip
.tar.gz
.sql
.config
.ini
.yml
.yaml
.json
.xml
.php
.js
.txt
.log
.gz
.tar
.conf
.bkp
.save
~1
~2

How to Use the Wordlist: Step-by-Step Commands

To make this wordlist actionable, you’ll need a list of subdomains (e.g., subdomains.txt) and tools like httpx, gobuster, or ffuf. Below are the exact commands to run the wordlist and find sensitive endpoints.

1. Prepare Your Environment

Install the required tools (Linux/Mac or WSL on Windows):

go install github.com/projectdiscovery/httpx/cmd/httpx@latest
go install github.com/OJ/gobuster/v3@latest
sudo apt install dirsearch  # or pip install dirsearch

Ensure tools are in your PATH (e.g., ~/go/bin).

2. Get a Subdomain List

If you don’t have a subdomain list, generate one with subfinder:

subfinder -d example.com -o subdomains.txt

This creates subdomains.txt with entries like dev.example.com, api.example.com.

3. Filter Live Subdomains

Use httpx to check which subdomains are live:

cat subdomains.txt | httpx -silent -o live-subdomains.txt

This outputs live-subdomains.txt with only accessible subdomains.

4. Save the Wordlist

Copy the wordlist above into a file named sensitive_endpoints.txt in your working directory.

5. Scan Subdomains with the Wordlist

Use gobuster to scan each live subdomain for sensitive endpoints:

gobuster dir -u <https://dev.example.com> -w sensitive_endpoints.txt -o results-dev.txt

To automate scanning across all live subdomains, use this Bash loop:

while IFS= read -r subdomain; do
  safe_subdomain=$(echo "$subdomain" | sed 's/http:\\/\\///g; s/https:\\/\\///g; s/\\//_/g')
  gobuster dir -u "$subdomain" -w sensitive_endpoints.txt -o "results_$safe_subdomain.txt" -q --no-error
done < live-subdomains.txt

This saves results in files like results_dev.example.com.txt.

6. Alternative Tool: ffuf

If you prefer ffuf for faster scanning:

ffuf -u <https://dev.example.com/FUZZ> -w sensitive_endpoints.txt -o results-dev.json

For all subdomains:

while IFS= read -r subdomain; do
  safe_subdomain=$(echo "$subdomain" | sed 's/http:\\/\\///g; s/https:\\/\\///g; s/\\//_/g')
  ffuf -u "$subdomain/FUZZ" -w sensitive_endpoints.txt -o "results_$safe_subdomain.json" -silent
done < live-subdomains.txt

7. Analyze Results

• Check output files for HTTP status codes:
• 200 OK: Endpoint exists (e.g., /config.json might leak API keys).
• 403 Forbidden: Could indicate a protected endpoint worth testing.
• 301/302 Redirect: Test for open redirects (e.g., /redirect with redirectUrl=evil.com).
• Use Burp Suite Community Edition to inspect promising endpoints (e.g., /service-worker.js, /api/users).
• For files like service-worker.js, test parameters like redirectUrl for open redirects or XSS using Burp’s Repeater.

Example Output

If gobuster finds endpoints on dev.example.com:

/service-worker.js (Status: 200)
/admin (Status: 403)
/api/v1/config (Status: 200)

• Next Steps: Visit https://dev.example.com/service-worker.js to check for sensitive logic (e.g., unvalidated redirects). Test /api/v1/config for data leaks or /admin for authentication bypasses.

Why This Wordlist Is Effective

• Comprehensive: Covers configuration files (.json, .env), APIs (/api/v1), admin panels (/admin), backups (.bak, .sql), and redirect endpoints (/service-worker.js).
• Real-World Inspired: Includes patterns from cases like exposed config.js files or OAuth misconfigurations (e.g., GitLab’s email verification bypass).
• Case-Sensitive Variations: Accounts for exploits like /METRICS vs. /metrics, as seen in inDrive reports.
• Tool-Friendly: Works seamlessly with gobuster, ffuf, or dirsearch for fast enumeration.

Tips for Finding Sensitive Endpoints

• Target Dev Subdomains: Subdomains like dev, staging, or test often host misconfigured endpoints.
• Test Redirects: For endpoints like /service-worker.js, manipulate parameters (e.g., redirectUrl=https://evil.com) to check for open redirects.
• Check APIs: Endpoints like /api/v1/users may leak data if unauthenticated. Use Burp Suite to send GET/POST requests.
• Historical Data: Use waybackurls to find old endpoints:

waybackurls https://sub.example.com | grep "\.json$" > archived-endpoints.txt

• Stay Ethical: Only scan subdomains within the bug bounty program’s scope.

When to Report Findings

• Report If: You find sensitive data (e.g., API keys in /config.json), unauthorized access (e.g., /admin), or exploitable flaws (e.g., open redirects in /service-worker.js).
• Don’t Report If: The endpoint is standard and non-exploitable (e.g., service-worker.js with no vulnerable parameters). Test first with Burp Suite.
• Craft a PoC: Include clear steps, screenshots, and impact in your report (e.g., “Accessing /api/users without auth leaks user emails”).

Conclusion

This sensitive endpoint wordlist is your key to uncovering vulnerabilities in bug bounty programs. By combining it with tools like gobuster or ffuf and the commands above, you can systematically scan subdomains for exposed files, APIs, or misconfigurations. Practice on platforms like PortSwigger’s Web Security Academy, stay within program scopes, and test endpoints like /service-worker.js for issues like open redirects. Your next bug is waiting—happy hunting!