Most people use Google to find answers.

Security researchers use Google to find vulnerabilities.

The technique is called Google Dorking — and it's one of the most powerful, most underrated, and most beginner-accessible recon skills in bug bounty hunting.

No special tools. No expensive software. Just Google, the right search operators, and knowing what you're looking for.

Here's exactly how I use it.

🤔 What Is Google Dorking?

Google Dorking (also called Google Hacking) is the practice of using advanced Google search operators to find specific information that isn't easily visible through normal searches.

Google constantly crawls and indexes the entire internet — including files, pages, and data that website owners never intended to be publicly accessible. Dorking lets you query that indexed data with surgical precision.

Think of it like this — Google has already found the exposed files. Dorking just helps you ask the right question to surface them.

Important: Google Dorking itself is not illegal. It uses publicly available information that Google has already indexed. However, accessing or exploiting any vulnerabilities you find without authorization absolutely is illegal. Always dork responsibly and only test targets you have permission to test.

🔧 The Operators I Use — And What They Do

site: — Scope Your Target

The site: operator limits results to a specific domain. This is always my starting point.

Basic usage:

site:target.com

hat it shows me: Every page Google has indexed for that domain. Instantly I can see the full surface area — subdomains, directories, file types.

More specific usage:

site:target.com filetype:pdf
site:*.target.com
site:target.com -www

The last one removes the main www subdomain and shows only other subdomains — great for finding forgotten or development subdomains.

inurl: — Find Specific URL Patterns

The inurl: operator searches for pages where the URL contains a specific word or string.

Usage:

inurl:admin site:target.com
inurl:login site:target.com
inurl:dashboard site:target.com
inurl:config site:target.com

What I'm looking for:

  • Admin panels that shouldn't be publicly accessible
  • Login pages across the target's subdomains
  • Dashboard URLs that might have weak authentication
  • Config files accidentally exposed in URLs

Pro tip:

inurl:php?id= site:target.com
inurl:page= site:target.com
inurl:redirect= site:target.com

These patterns often reveal URL parameters — which are prime targets for injection and redirect vulnerabilities.

intitle: — Search Page Titles

The intitle: operator searches for pages where the title contains a specific word.

Usage:

intitle:"index of" site:target.com
intitle:"admin panel" site:target.com
intitle:"dashboard" site:target.com
intitle:"phpMyAdmin" site:target.com

What I'm looking for:

intitle:"index of" is one of my favourites. It finds open directory listings — pages where the web server is literally showing a file browser of its own directories. These often expose backup files, config files, and sensitive documents.

intitle:"phpMyAdmin" finds exposed database management interfaces — which should never be publicly accessible.

filetype: — Hunt Specific File Types

The filetype: operator searches for specific file extensions. This is where things get really interesting.

Usage:

filetype:pdf site:target.com
filetype:xls site:target.com
filetype:csv site:target.com
filetype:sql site:target.com
filetype:log site:target.com
filetype:env site:target.com
filetype:bak site:target.com

What each one can reveal:

  • .pdf / .xls / .csv — documents that may contain sensitive data
  • .sql — database dumps accidentally left on the server
  • .log — server logs that can leak internal info and errors
  • .env — environment files containing API keys, database credentials, secrets
  • .bak — backup files of source code or databases

Finding a .env file or a .sql dump on a target is a critical finding in almost any bug bounty program.

intext: — Search Page Content

The intext: operator searches for specific text within the body of a webpage.

Usage:

intext:"password" filetype:log site:target.com
intext:"api_key" site:target.com
intext:"DB_PASSWORD" site:target.com
intext:"SQLException" site:target.com
intext:"Warning: mysql" site:target.com

What I'm looking for:

  • Logs or pages that contain the word "password" — could be credentials leaked in error messages
  • Pages exposing API keys or database credentials in their content
  • SQL error messages — a strong indicator of potential SQL injection points
  • MySQL warnings visible to the public — server misconfiguration

cache: — See Old Versions of Pages

The cache: operator shows Google's cached (saved) version of a page — what it looked like the last time Google crawled it.

Usage:

cache:target.com/admin
cache:target.com/config

What it's useful for: Sometimes pages get taken down or patched after a vulnerability is discovered — but Google's cache still has the old version. This can reveal what was previously exposed.

It's also useful for seeing content on pages that are temporarily down, or for comparing the current version of a page to an older cached version.

🧩 Combining Operators — Where the Magic Happens

The real power of Google Dorking comes from combining operators together.

Here are some of my favourite combinations:

Find exposed environment files:

filetype:env intext:"DB_PASSWORD" site:target.com

Find open directory listings with backup files:

intitle:"index of" inurl:backup site:target.com

Find login pages across all subdomains:

inurl:login site:*.target.com

Find SQL error messages (SQLi indicators):

intext:"SQLException" OR intext:"mysql_fetch" site:target.com

Find exposed config files:

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

Find vulnerable redirect parameters:

inurl:redirect= site:target.com
inurl:url= site:target.com
inurl:next= site:target.com

⚠️ Google Dorking Ethics — Read This

Google Dorking surfaces information that is technically public — Google has already indexed it. But that doesn't mean everything you find is fair game.

Always remember:

  • Only test targets you have explicit permission to test
  • Finding sensitive data doesn't mean you can access, download, or exploit it
  • If you find something serious on a target in scope, report it responsibly
  • Never use dorking to target individuals or access private data

The goal is to find vulnerabilities so they can be fixed — not to cause harm.

For safe practice: Use Google Dorks on your own test environments, or on platforms like HackTheBox and TryHackMe that explicitly allow it. The GHDB (Google Hacking Database) at exploit-db.com/google-hacking-database is a great resource for learning more dork patterns.

🛠️ My Google Dorking Workflow

Here's exactly how I approach dorking on a new target:

Step 1 — Map the surface

site:target.com
site:*.target.com -www

Get a feel for how many pages and subdomains exist.

Step 2 — Hunt for sensitive files

filetype:env OR filetype:sql OR filetype:log OR filetype:bak site:target.com

Step 3 — Find admin and login pages

inurl:admin site:target.com
inurl:login site:*.target.com
intitle:"admin" site:target.com

Step 4 — Look for exposed data

intext:"password" filetype:log site:target.com
intext:"api_key" site:target.com
intitle:"index of" site:target.com

Step 5 — Hunt vulnerable parameters

inurl:id= site:target.com
inurl:page= site:target.com
inurl:redirect= site:target.com

This whole workflow takes me 10–15 minutes and gives me a solid picture of the target's exposed surface before I even open Burp Suite.

🏁 Final Thoughts

Google Dorking is proof that you don't need expensive tools or advanced skills to start finding real security issues.

The information is already out there — indexed, searchable, waiting. All you need is the right query and the knowledge of what you're looking for.

It's one of the first techniques I learned, and it's still one of the first things I run on any target. Simple, free, and surprisingly powerful.

Start with site: and go from there. You might be surprised what Google has already found. 🔍

Found this useful? Follow for more practical cybersecurity content. Drop your favourite dork in the comments — I'd love to see what you're finding. 🙌

⚠️ Disclaimer: All techniques in this blog are for educational purposes and authorized security testing only. Never use these techniques on targets you don't have permission to test. Always practice responsible disclosure.