September 7, 2026
Common Sensitive Files You Should Look For During Web Recon
A beginner-friendly guide to finding publicly accessible files that can reveal valuable information during bug bounty reconnaissance.

By Monika
3 min read
Imagine you're testing a web application.The homepage looks normal. The login page works as expected, and the visible features don't reveal anything interesting.
Does that mean there's nothing left to investigate?
Not necessarily.
Some of the most valuable information isn't hidden behind complicated vulnerabilities. Sometimes it's sitting inside files that were never meant to be publicly accessible.
Over the past few months, while learning reconnaissance, I've made it a habit to check for common sensitive files before diving into deeper testing. Most of the time I don't find anything unusual but every now and then I come across files that reveal useful information about the application's structure.
In this article, I'll share the files I usually check during reconnaissance and explain why they're worth a quick look.
What Are Sensitive Files?
Sensitive files are documents or configuration files that can expose information about a web application.
Finding one doesn't automatically mean you've discovered a vulnerability.
these files can provide valuable clues that help you understand how an application is built and where to focus your testing.
robots.txt
The first file I check is:
https://example.com/robots.txthttps://example.com/robots.txt
Most websites use this file to tell search engines which pages should or shouldn't be indexed.
Sometimes developers accidentally list interesting directories such as:
/admin/
/backup/
/private/
/test//admin/
/backup/
/private/
/test/Even if those directories aren't accessible, their names can provide useful reconnaissance information.
sitemap.xml
Another file that's almost always worth checking is:
https://example.com/sitemap.xmlhttps://example.com/sitemap.xml
Sitemaps often contain hundreds of URLs.
Sometimes you'll discover pages that aren't linked anywhere on the homepage.
This is one of the easiest ways to expand your target list before crawling the application.
security.txt
More organizations are now publishing a security.txt file.
https://example.com/.well-known/security.txthttps://example.com/.well-known/security.txtThis file usually contains:
- Security contact information
- Bug bounty details
- Responsible disclosure policy
- Preferred reporting method
Before testing a target, I always check whether this file exists.
.git Directory
One of the first things I verify is whether the Git repository is accidentally exposed.
For example:
https://example.com/.git/https://example.com/.git/If directory listing is enabled or repository files are exposed, it could reveal valuable information about the application's source code.
In most cases you'll simply receive a 403 or 404 response, which is completely normal.
Backup Files
Developers sometimes leave backup copies on production servers.
Examples include:
backup.zip
website.zip
site.tar.gz
backup.sql
db.sqlbackup.zip
website.zip
site.tar.gz
backup.sql
db.sqlThese files shouldn't normally be accessible, but checking for common names takes very little time.
Environment Files
Another file I always keep in mind is:
.env.envA properly configured server should never expose this file publicly.
If it's accessible, it may contain application configuration details.
Never assume it exists, but it's worth checking when you're working within an authorized scope.
Configuration Files
Depending on the application, configuration files may also be interesting.
Examples include:
config.php
config.json
config.yaml
settings.jsonconfig.php
config.json
config.yaml
settings.jsonMost applications protect these files correctly, but occasionally they expose information about the application's structure.
API Documentation
Some organizations accidentally leave API documentation publicly available.
Examples include:
/swagger
/swagger-ui
/api/docs
/openapi.json/swagger
/swagger-ui
/api/docs
/openapi.jsonEven when authentication is required, the documentation itself can help you understand available endpoints.
Log Files
Occasionally you'll encounter log files such as:
error.log
access.log
debug.logerror.log
access.log
debug.logMost servers protect these files, but checking for them is part of a thorough reconnaissance process.
How I Usually Search for These Files
Instead of checking everything manually, I usually combine several approaches.
- Google Dorks
- Katana
- waymore
- Cariddi
- Directory brute-forcing
- Manual verification
Using multiple techniques gives me better coverage than relying on a single tool.
Don't Expect Every File to Exist
One mistake I made as a beginner was expecting every website to expose something interesting.
That's rarely the case.
Most modern applications are configured correctly.
The goal isn't to "find a sensitive file on every target."
The goal is to build a consistent reconnaissance process that doesn't overlook simple opportunities.
Sometimes you'll find nothing.
Sometimes one overlooked file gives you a much better understanding of the application.
A Few Good Habits
Here are a few habits that have helped me during reconnaissance:
- Keep a checklist of files you want to verify.
- Save interesting URLs for later analysis.
- Don't rely on a single reconnaissance tool.
- Read the contents carefully instead of assuming they're unimportant.
- Always stay within the scope of the bug bounty program.
Good reconnaissance is often about patience rather than speed.
Wrapping Up
Sensitive files are often overlooked because they're simple to check.
Yet they can reveal endpoints, directories, documentation, and other details that make the rest of your testing more focused.
Even if you don't discover anything sensitive, spending a few minutes checking these common files is a habit worth developing.
As I continue learning bug bounty, this remains one of the first steps in my reconnaissance routine because it's quick, easy, and sometimes surprisingly rewarding.
Need Help?
If you're learning bug bounty and have questions about reconnaissance or the tools mentioned in my articles, feel free to reach out.
๐ Connect with me
X (Twitter): @Commanak46
I'm always happy to connect with other beginners and share what I've learned.
Happy hunting โจ