Post cover image

August 14, 2026

Dorks that could get you a good bounty in 2026

Google can index far more than publicly intended webpages. During an authorized bug bounty assessment, search operators can help…

By Deepanshu Deep

3 min read

Google can index far more than publicly intended webpages. During an authorized bug bounty assessment, search operators can help researchers discover exposed files, forgotten directories, configuration files, backups, and other publicly indexed information that may reveal security weaknesses.

Important:_ Only use these techniques against systems you own or targets where you have explicit authorization, such as a bug bounty or vulnerability disclosure program._

1. Discover Exposed Files

One of the easiest places to start is with files that should generally not be publicly indexed.

intitle:"index of" site:target.com
filetype:log site:target.com
filetype:sql site:target.com
filetype:env site:target.com

An index of result may reveal directory listings, while log, sql, and env files can sometimes contain sensitive operational information.

The goal is not simply to find a file, but to determine whether the file is unintentionally exposed and whether the information inside it creates a security impact.

2. Find Sensitive Directories

Certain URL patterns are commonly associated with administrative panels, debugging pages, backups, or application components.

site:target.com inurl:phpinfo.php
site:target.com inurl:admin
site:target.com inurl:backup
site:target.com inurl:wp-

For example, phpinfo.php can expose PHP configuration details, while publicly accessible administrative paths may reveal additional attack surface.

Finding a URL does not automatically mean it is vulnerable. Always verify whether the endpoint is actually accessible and whether it falls within the program's scope.

3. Locate Configuration Files

Configuration files are particularly interesting during reconnaissance because they may contain application settings, database information, service endpoints, or environment-specific values.

site:target.com filetype:config
site:target.com filetype:ini
site:target.com filetype:json inurl:config

A configuration file might expose useful information such as API endpoints, internal hostnames, feature flags, or other implementation details.

Never assume that every discovered configuration file contains secrets. The important question is whether the exposure creates a security impact.

4. Search for Exposed Credentials

Poorly protected logs and database exports can sometimes contain usernames, passwords, tokens, or other authentication-related information.

site:target.com filetype:log intext:"password"
site:target.com filetype:log intext:"username"
site:target.com filetype:sql "password"

These searches can generate a lot of false positives, so results should be carefully reviewed.

When a credential is discovered during an authorized assessment, avoid unnecessary access to unrelated accounts or systems. Document the finding and follow the program's disclosure rules.

5. Find Database Dumps

Database backups and SQL dumps are another interesting area for reconnaissance.

site:target.com filetype:sql inurl:db
site:target.com filetype:sql inurl:dump
site:target.com filetype:bak inurl:db

A publicly accessible SQL dump could potentially expose application data, table structures, usernames, email addresses, or other sensitive information.

Even when the data itself appears harmless, database structure can reveal valuable information about how an application is built.

6. Detect Exposed Git Repositories

Git repositories can unintentionally expose source code, commit history, configuration files, and development information.

site:target.com inurl:.git
site:target.com inurl:/.git/config
site:target.com intitle:"index of" ".git"

A publicly accessible .git directory can sometimes provide much more information than a normal source-code page because Git repositories contain historical project data.

Pay particular attention to accidentally committed secrets, internal endpoints, and credentials.

7. Find Publicly Exposed Email Addresses

Search engines can also help identify email addresses associated with a target organization.

site:target.com intext:"@target.com"
site:target.com inurl:contact "@target.com"
site:target.com filetype:xls "@target.com"

This can be useful for understanding the organization's publicly exposed contact surface.

For bug bounty work, this information can also help researchers identify whether employee or organizational data has been unintentionally published.

8. Identify Default Web Server Pages

Default server pages can reveal technologies, server software, or environments that were deployed without being properly configured.

site:target.com intitle:"Apache2 Ubuntu Default Page: It works"
site:target.com intitle:"Index of /" "Apache Server"
site:target.com intitle:"Welcome to nginx"

These results are not necessarily vulnerabilities on their own.

However, they can reveal forgotten hosts, development environments, staging infrastructure, or systems that were never fully hardened.

9. Search for Exposed API Keys and Secrets

Environment files and configuration files are especially interesting when looking for accidentally exposed secrets.

site:target.com filetype:env "DB_PASSWORD"
site:target.com filetype:env "API_KEY"
site:target.com filetype:env "AWS_ACCESS_KEY_ID"

A search result containing a secret does not automatically mean it is exploitable. Determine whether the value is real, active, sensitive, and associated with the target.

Avoid using discovered credentials to access unrelated resources. Responsible disclosure should focus on proving impact with minimal interaction.

10. Locate Backup Files

Developers often create backups during deployments, migrations, or troubleshooting. These files can remain publicly accessible long after they are needed.

site:target.com filetype:bak
site:target.com filetype:zip inurl:backup
site:target.com filetype:tar.gz
site:target.com filetype:tgz

Backup archives can contain source code, configuration files, databases, logs, and other internal information.

Because of that, accidentally exposed backups can sometimes become a high-impact finding.

Putting It All Together

Google dorks are most effective when they are treated as one part of a broader reconnaissance process rather than as standalone vulnerability-finding commands.

A typical workflow might look like this:

Domain → Indexed files → Sensitive directories → Configuration → Backups → Source code → Secrets → Manual verification

For example, you could start with:

site:target.com

Then gradually narrow the search:

site:target.com filetype:env
site:target.com filetype:sql
site:target.com filetype:bak
site:target.com inurl:admin
site:target.com inurl:.git

The key is to combine search-engine reconnaissance with manual validation.

Final Thoughts

Google dorking is a simple but powerful reconnaissance technique for bug bounty hunters. It can help uncover forgotten assets and accidentally indexed information that may otherwise be difficult to locate.

At the same time, search results alone are not proof of a vulnerability. Always verify the finding, assess the actual impact, minimize interaction with sensitive data, and follow the rules of the relevant bug bounty program.

Used responsibly, Google can become an extremely useful reconnaissance tool in a bug bounty workflow.

If you found this write-up useful, feel free to follow me for more bug bounty and security research content.

You can also connect with me on LinkedIn and follow my work in cybersecurity and vulnerability research and OSINT. 🔐💻