Google Dorks for bug bounty: recon with search engines (guide + examples)

Quick answer: Google Dorks are advanced searches that use special operators (site:, inurl:, filetype:, intext:...) to find exposed information that a normal search hides: login panels, sensitive files, forgotten subdomains or leaked data. In bug bounty they're a very powerful passive reconnaissance technique, as long as you use them only within the scope of a program.

What are Google Dorks?

A Google Dork (or Google hacking) is a query that leverages Google's search operators to filter the index and surface pages and files you wouldn't normally find by browsing. Google has crawled half the internet; dorks are the way to ask it exactly what interests you.

The idea isn't to hack Google: it's to hack with Google. Many companies unintentionally expose admin panels, backups, credentials in config files or internal endpoints that the search engine has indexed. A well-built dork finds them in seconds, without firing a single request at the target (which is why it's passive recon).

For a bug bounty hunter, dorks are one of the first cards of reconnaissance: cheap, fast and surprisingly effective.

Which search operators should you know?

These are the building blocks any dork is made of:

They combine freely. The trick is chaining them to narrow down more and more:

site:target.com inurl:admin
site:target.com filetype:pdf intext:"confidential"
site:target.com -www -shop

Dorks for bug bounty (examples by goal)

Replace target.com with the domain you have in scope. These are common patterns:

Sensitive information exposure

# Listable directories (open directory listing)
site:target.com intitle:"index of"

# Config files and environment variables
site:target.com ext:env OR ext:ini OR ext:conf
site:target.com filetype:log

# Leaked internal documents
site:target.com filetype:pdf intext:"internal" OR intext:"confidential"

# Backups and database dumps
site:target.com ext:sql OR ext:bak OR ext:old OR ext:backup

Login and admin panels

site:target.com inurl:admin
site:target.com inurl:login
site:target.com intitle:"admin panel" OR intitle:"dashboard"
site:target.com inurl:wp-admin

An indexed admin panel is an obvious entry point: aim at access control and IDOR flaws, default credentials or weak authentication.

Interesting files and parameters

# Endpoints with parameters (candidates to test)
site:target.com inurl:"id="
site:target.com inurl:"redirect=" OR inurl:"url=" OR inurl:"next="

# Keys and tokens exposed in JS or text files
site:target.com ext:js intext:"api_key" OR intext:"apikey"

Parameters like url= or redirect= are classic hints of open redirect and SSRF; a numeric id= invites you to test IDOR.

Enumerate subdomains and forgotten assets

# Indexed subdomains (excluding the main one)
site:*.target.com -www

# Dev and test environments that shouldn't be public
site:target.com inurl:dev OR inurl:staging OR inurl:test

The dev, staging or test subdomains usually have fewer protections than production and are fertile ground.

Dorks in other search engines and on GitHub

Google isn't the only index. The same philosophy applies to:

• Bing / DuckDuckGo: similar operators; sometimes they index things Google doesn't.
• GitHub Dorking: search the public code for company leaks (org:targetorg filename:.env, "target.com" api_key). Developers upload secrets to repositories more than you'd think.
• Shodan / Censys: instead of pages, they index exposed services and devices (ports, banners, databases). They complement web dorks perfectly.

I expand on these sources in the advanced recon techniques guide.

Dorks for specific technologies and error messages

Another rich vein: searching by the fingerprints left by known technologies or the errors that reveal the application's guts.

# Specific panels and software
site:target.com inurl:phpmyadmin
site:target.com intitle:"Grafana"
site:target.com inurl:jenkins

# Error messages that leak paths or queries
site:target.com intext:"sql syntax near"
site:target.com intext:"stack trace" OR intext:"exception"

# Exposed API documentation
site:target.com inurl:swagger OR inurl:"api-docs"

An indexed SQL error suggests a possible SQL injection; a stack trace leaks internal paths and versions; a public Swagger hands you the entire API map (perfect for hunting IDOR endpoint by endpoint).

Combos that raise the score

Chaining operators is where the magic is. Some combos that tend to bear fruit:

# Text files with credentials
site:target.com ext:txt intext:"password" OR intext:"pwd"

# Upload forms (file upload candidates)
site:target.com inurl:upload

# File inclusion parameters (LFI candidates)
site:target.com inurl:"file=" OR inurl:"page=" OR inurl:"path="

A file= or page= parameter is a classic candidate for LFI; an upload form invites you to test file upload. The dork only takes you to the door; opening it depends on you recognizing the pattern.

How to automate dorks?

Firing dorks by hand is fine to start, but it gets slow with many targets. Ways to scale it up, always with care so the search engine doesn't block you:

• Google Hacking Database (GHDB): the Exploit-DB repository with thousands of classified dorks. Use it as a catalog to copy and adapt from.
• Combine dorks with a list of domains. With a list of dorks and another of in-scope domains you can generate all the combinations and review them in an orderly way.
• Dorking tools. There are scripts that automate queries, but respect the search engine's limits: massive, aggressive querying ends in captchas or temporary IP blocks. Dorking is a surgical technique, not a brute-force scanner.
• Don't stay only on Google. Bing, DuckDuckGo, Yandex and the code search engines index different things. And for infrastructure, Shodan and Censys are the equivalent of dorks but over services and ports.

Automation gives you volume, but the judgment remains human: of 200 results, the value is in the 3 you recognize as potentially vulnerable. That eye is trained by studying real flaws, not by accumulating dork lists.

Ethical use: only within scope

A non-negotiable point. Searching with Google is legal, but acting on what you find isn't always:

• Only apply dorks to domains that are in the scope of a bug bounty program or an authorized pentest.
• Finding isn't accessing. Google showing you a backup or a panel doesn't authorize you to download it or enter if it's out of scope or belongs to a third party.
• Don't touch real user data. If a dork reveals personal information, document the exposure and report it; don't extract or keep it.
• When in doubt, don't do it and ask the program team.

The line between legitimate reconnaissance and crime is, once again, authorization. A dork that finds a leak at a company without a program isn't a bug bounty finding: it's information you have no business touching.

How do dorks fit into your recon methodology?

Dorks aren't an end in themselves: they're an early phase of reconnaissance. A typical flow:

1. Define the scope. An exact list of allowed domains and subdomains.
2. Passive recon with dorks. Look for panels, files, parameters and indexed subdomains without touching the target.
3. Cross-reference with other sources: subdomain enumeration, JavaScript analysis, Wayback Machine, GitHub. All of that is in advanced recon techniques.
4. Prioritize targets. Of everything found, pick what smells like a flaw: an old panel, a url= parameter, a staging subdomain.
5. Move to the active phase. There you intercept with Burp and test specific vulnerabilities, ideally recognizing patterns you've trained before in real-case labs.

Dorks tell you where to look; vulnerability knowledge tells you what to test when you get there. Without the latter, a good dork only gives you a URL you don't know how to exploit. That's why it's worth training the flaw pattern in the Academy alongside recon.

Frequently asked questions (FAQ)

Is it legal to use Google Dorks?
Searching is legal. What may not be is accessing, downloading or exploiting what you find if it's out of scope or belongs to a third party without authorization. Use them only on allowed targets.

Do dorks still work in 2026?
Yes. Google tweaks its index and sometimes removes sensitive results, but reconnaissance with operators is still a living technique widely used by hunters and security teams.

Where do I find lists of dorks?
The Google Hacking Database (GHDB) from Exploit-DB collects thousands of dorks by category. Use it for inspiration, but always adapt the queries to your specific target.

Do dorks replace recon tools?
No, they complement them. They're the passive, manual part; enumeration tools automate and expand the surface. The best is to combine them.

Which is the best operator to start with?
site: combined with inurl: or filetype:. With those three you cover most useful cases: narrowing to the in-scope domain and filtering by paths or by interesting file type. The rest are refinements.

Can I get my own website indexed to test dorks?
Yes, and it's the safest way to practice: set up your own environment or use a deliberately vulnerable site and observe what it exposes. That way you train the operators without brushing against anyone's scope. Once you master them, apply them only to authorized targets.

Conclusion

Google Dorks are one of the reconnaissance techniques with the best effort/result ratio in bug bounty: with four well-combined operators you surface panels, files and subdomains that others overlook, and without touching the target. The rule is simple: use them only within scope, don't confuse finding with accessing, and treat them as the first step of a broader recon. Combine them with the advanced recon techniques and, above all, train your eye to know what to do with what you find by reproducing real flaws in the labs.