Post cover image

October 14, 2026

Google Dorking: How I Use Search Engines to Find Hidden Vulnerabilities

A beginner-friendly walkthrough of the recon technique that has helped me find real bugs on bug bounty targets no expensive tools needed…

By Monika

4 min read

A beginner-friendly walkthrough of the recon technique that has helped me find real bugs on bug bounty targets no expensive tools needed, just smart search queries.

Most people think hacking starts with Burp Suite or some fancy exploit script. Honestly? It doesn't. It starts with information. And one of the most underrated ways to collect that information is something you already use every day — Google.

This technique is called Google Dorking also known as Google Hacking and in this article, I'll walk you through exactly how I use it during recon to uncover exposed files, admin panels, misconfigured servers, and sometimes even leaked credentials all using advanced search operators.

Let's break it down step by step.

What Exactly Is Google Dorking?

Google Dorking means using special search operators to make Google (or Bing, DuckDuckGo, etc.) dig up information that isn't meant to be publicly visible — but got indexed anyway because of a misconfiguration.

Think of it like this: search engines crawl and index everything they can reach. If a company accidentally leaves a sensitive file, a login page, or a config file open to the internet with no restrictions, Google will index it. Dorking is just the skill of asking Google the right question to pull that file out of millions of indexed pages.

It's 100% passive recon — you're not touching the target's server directly, you're just querying a search engine. That's what makes it such a great first step in any bug bounty methodology.

The Basic Operators You Need to Know

Here are the core search operators I use almost every single time I start recon on a new target:

  • site: — restricts results to one domain. Example: site:target.com
  • inurl: — finds a keyword inside the URL. Example: inurl:admin
  • intitle: — finds a keyword inside the page title. Example: intitle:"index of"
  • filetype: — searches for a specific file extension. Example: filetype:pdf
  • intext: — finds a keyword inside the actual page content. Example: intext:"password"
  • ext: — same as filetype, shorthand version.
    • (minus sign) — excludes a word from results. Example: site:target.com -www
  • " " (quotes) — searches for an exact phrase.
    • — wildcard, useful when you're not sure of the exact word.

You combine these to build powerful queries called dorks.

Real Dorks I Use During Recon (Step-by-Step Walkthrough)

Here's how I actually structure my recon session on a new target. I'll explain why I run each query, not just what it is.

Step 1: Map the Subdomains and Attack Surface

site:.target.com

This shows me every indexed subdomain Google knows about. Sometimes old, forgotten subdomains (like dev.target.com or staging.target.com) show up here — and those are often less secure than the main site.

Step 2: Find Exposed Directory Listings

site:target.com intitle:"index of"

Directory listing means the server is literally showing you a folder structure instead of a proper webpage. If this is exposed, you might find backup files, source code, or config files sitting right there.

Step 3: Hunt for Exposed Login & Admin Panels

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

This helps me find panels that maybe aren't linked anywhere on the main website but are still live and accessible.

Step 4: Look for Sensitive File Types

site:target.com filetype:env
site:target.com filetype:log
site:target.com filetype:sql
site:target.com filetype:xml
site:target.com filetype:json
site:target.com filetype:bak

.env files are gold — they sometimes contain API keys, database credentials, or secret tokens that were never meant to be public. .sql and .bak files can leak entire database structures.

Step 5: Search for Error Messages & Debug Info

site:target.com intext:"error" intext:"warning"
site:target.com intext:"sql syntax near"

Exposed error messages (like SQL syntax errors) are a strong hint of a potential SQL Injection point, or at the very least, that the app leaks internal stack traces — which is itself a finding.

Step 6: Find Exposed API Documentation or Swagger Files

site:target.com inurl:swagger
site:target.com inurl:api-docs
site:target.com filetype:json inurl:swagger

API documentation that's publicly exposed often reveals endpoints that were never meant to be tested externally — a great starting point for deeper API testing.

Step 7: Check for Leaked Credentials in Public Pastes

site:pastebin.com "target.com" password
site:github.com "target.com" api_key

Yes — people (including developers) accidentally push secrets to GitHub or Pastebin. A well-crafted dork here can surface leaked tokens tied to your target's domain.

Step 8: Find Exposed Configuration Files

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

Config files often contain internal paths, database hostnames, or service credentials — super useful for building a bigger picture of the target's infrastructure.

Pro Tip: Combine Dorks for Laser-Focused Results

Don't just run one dork and stop. Chain your logic. For example:

site:target.com (filetype:env OR filetype:log OR filetype:sql) intext:"DB_PASSWORD"

This single query is specifically hunting for files that are likely to contain database credentials. The more specific your dork, the less noise you have to dig through.

Tools That Make Dorking Even Faster

Once you're comfortable with manual dorking, these tools can automate and scale the process:

  • Google Hacking Database — a massive library of ready-made dorks maintained by Exploit-DB.
  • dorks-eye — a Python tool that automates dork searches.
  • Pagodo — automates Google dork scraping using the GHDB.
  • Shodan / Censys — not technically "dorking," but a great companion tool once you've mapped the attack surface, since they index internet-facing devices and services directly.

A Real Example of Why This Works

On one of my recon sessions, a simple filetype:env dork on a target's domain surfaced a cached .env file that had already been removed from the live server — but Google's cache still had a copy. That one file revealed internal service names which helped me understand the tech stack better before I even opened Burp Suite.

This is the power of dorking it's recon done entirely from the comfort of a search bar, before you fire a single request at the actual server.

Important: Stay Within Legal & Ethical Boundaries

Before you go dork-hunting on any target, remember:

  • Only test targets where you have explicit permission — a live bug bounty program with the domain in scope, or your own lab/test environment.
  • Dorking itself is passive (you're just querying Google), but what you do with the information you find can cross legal lines if you access systems without authorization.
  • Always check the program's scope and rules on platforms like HackerOne or Bugcrowd before testing.
  • If you find something sensitive like exposed credentials, report it responsibly through the program's disclosure process — don't use it yourself.

If this helped you understand dorking better, try running a few of these queries (ethically, on in-scope targets only) and see what you uncover. You'll be surprised how much is sitting out there in plain sight.

If you found this useful, follow me for more beginner-friendly bug bounty and cybersecurity writeups.

Monika Hi, I'm Monika ✨I break down real-world bug bounty reports into simple, practical write-ups.If my articles help you…