Post cover image
Photo by Markus Spiske on Unsplash

August 4, 2026

100 High-Value Files & Paths Every Bug Hunter Should Check During Recon

An ethical bug bounty recon checklist for discovering exposed configuration, source code, backups, secrets, documentation, logs, and other…

By Tejas Kamble

4 min read

An ethical bug bounty recon checklist for discovering exposed configuration, source code, backups, secrets, documentation, logs, and other sensitive files.

Hey Guys, past few days i am doing bug hunting, most fun part is to doing bug hunting — "recon". While doing this i start thinking about where to start it which files should i look for it. Surprisingly i found my first bug but it status is duplicate. What i am saying that sometimes only doing information gathering/recon we can find vulnerability. Today in this article i tell you most of files and path which you should look for it during recon.

Disclaimer: This article is intended for authorized security testing, bug bounty programs, CTFs, and security labs. Only test assets explicitly permitted by the target's scope and program policy. Do not access, download, or disclose sensitive information unnecessarily.

Reconnaissance is one of the most important phases of a bug bounty assessment. Before looking for SQL injection, XSS, IDOR, SSRF, or other vulnerabilities, a bug hunter should understand the application's attack surface.

One useful part of that process is identifying interesting files and paths that developers may accidentally expose.

A seemingly harmless file such as:

/robots.txt

could reveal interesting directories.

A backup file such as:

/config.php.bak

could potentially expose application source code.

An accidentally exposed:

/.env

could contain credentials, API keys, or other secrets.

The important lesson is:

The filename itself is not the vulnerability. The information exposed through it determines the security impact.

START →

How to use the checklist against target, don't use request blindly every target. Better approach is as follows :)

  1. Confirm the domain is in scope.
  2. Identify the application technology stack. (by using extension like wappalyzer or u know other things to know about technology that good)
  3. Look for paths relevant to that technology.
  4. Check wheather the resource is publicaly accessible.
  5. Determine what information is exposed.
  6. Assess whether the information is sensitive.
  7. Avoid unnecessary access to personal or confidential information.
  8. Follow the program's disclosure rules.

for ex,. Technology detected -> wordpress -> prioritize WordPress-related files -> check configuration / backup exposure -> Determine whether sensitive information is actually exposed

Critical — Priority 1

These files can potentially expose credentials, secrets, source code, or highly sensitive infrastructure information.

None

1. /.env

Common in Laravel, Node.js, Django deployments, and other applications.

Potential contents:

DB_HOST=
DB_USERNAME=
DB_PASSWORD=
API_KEY=
SECRET_KEY=
APP_SECRET=

An exposed .env file containing valid secrets can be extremely serious.

2. /.git/config

May indicate that Git metadata is publicly accessible.

It can reveal:

  • Repository information
  • Remote repository URLs
  • Branch configuration
  • Development information

The presence of .git/config alone does not necessarily mean sensitive source code is exposed.

3. /.git/HEAD

Git's HEAD file can confirm that Git metadata is accessible from the web server.

Potential impact becomes much greater when additional Git metadata is also exposed.

4. /.git/index

The Git index contains information about tracked files.

An accidentally exposed .git directory can potentially allow reconstruction of repository contents.

5. /config.php

A common configuration filename in PHP applications.

Potentially contains:

  • Database credentials
  • Connection strings
  • Application settings
  • API credentials

6. /wp-config.php

One of the most important WordPress configuration files.

It may contain database configuration and security-related secrets.

7. /database.sql

Potentially contains a database export.

Possible exposure includes:

  • User records
  • Email addresses
  • Application data
  • Database schema
  • Password hashes

A real production database dump can represent a critical data exposure.

8. /dump.sql

Another common database dump filename.

Treat database dumps as highly sensitive and avoid unnecessarily downloading or processing personal data.

9. /backup.sql

Potentially exposes a backup of application data.

The severity depends heavily on whether the file contains real production information.

10. /backup.zip

Compressed backups can contain entire applications, configuration files, source code, or databases.

11. /site.zip

A compressed copy of the website can potentially expose application source code and configuration.

12. /www.zip

Another filename sometimes used for web-root backups.

13. /application.properties

Common in Java/Spring applications.

Potentially contains:

  • Database settings
  • Application secrets
  • Internal service configuration

14. /application.yml

A YAML configuration file frequently used by modern applications.

Look for sensitive configuration rather than simply reporting its existence.

15. /application.yaml

Same general concern as application.yml.

16. /settings.py

Common in Django applications.

Potentially contains:

  • Secret keys
  • Database configuration
  • Debug settings
  • Internal application configuration

17. /web.config

Common in ASP.NET/IIS environments.

May contain application configuration and connection strings.

18. /docker-compose.yml

Can reveal:

  • Internal service names
  • Database configuration
  • Ports
  • Environment variables
  • Infrastructure architecture

19. /docker-compose.yaml

Same concern as the .yml variant.

20. /Dockerfile

May reveal:

  • Base images
  • Internal directories
  • Dependencies
  • Build process
  • Configuration assumptions

It isn't automatically sensitive, but it can provide useful information during recon.

Note : I am only put a Critical Priority list in article other High, Medium, Lower Priority list is on my GITHUB account.

For all content you can visit below github link,

Github link : https://github.com/TeJaS355/bug-bounty-recon-100.git

# What Makes a File Vulnerable?

None

This is one of the most important concepts for beginners.

Finding:

/robots.txt

doesn't automatically mean:

Vulnerability

Finding:

/.env

also doesn't automatically mean:

Critical vulnerability

You need to evaluate what is actually exposed.

For example:

Case 1 — Public robots.txt

/robots.txt

Contains:

Disallow: /admin/

Usually:

Informational / Not a vulnerability

Case 2 — Public .env

Suppose the response contains:

APP_ENV=production
DB_HOST=internal-db
DB_USERNAME=example
DB_PASSWORD=REDACTED

This is much more interesting.

If valid credentials or secrets are exposed, impact could be significant.

Case 3 — Backup source code

Suppose:

/config.php.bak

returns the application's PHP source instead of executing it.

That can expose:

$db_host = "...";
$db_user = "...";
$db_password = "...";

Now you're dealing with potential source-code and credential disclosure rather than merely discovering a file.

None

Finally,

Reconnaissance isn't about finding as many URLs as possible — it's about finding the right information and understanding why it matters.

A forgotten backup, exposed configuration file, debug log, or API specification might look insignificant at first, but when combined with other discoveries, it can reveal valuable information about an application's architecture and security posture.

The 100 paths in this checklist are not a magic formula. Use them as a starting point, adapt them to the target's technology stack, and always think beyond the filename:

What is exposed? Why is it exposed? Who can access it? And what could an attacker realistically do with it?

Keep learning, keep testing responsibly, respect program scope, and most importantly — think like an attacker, report like a professional.

Happy hunting! … :)

Bye!