The community
Inside people ask, share what they found and solve together what would block anyone on their own. It's free to join: no account, no plan, no email required.
Free and open. You don't need a BBLABS account to join.
Google Dorks guide for bug bounty: what they are, the operators (site:, inurl:, intitle:, filetype:, ext:, intext:), ready-to-use examples for info exposure, panels, sensitive files and subdomains, ethical use within scope and how they fit into your recon.
Gorka El Bochi
Founder of BBLABS
Stop reading about bugs and start hunting them
No card · free Academy · cancel anytime
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.
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.
These are the building blocks any dork is made of:
| Operator | What it does | Example |
|---|---|---|
site: |
Limits to a domain | site:target.com |
inurl: |
The string appears in the URL | inurl:admin |
intitle: |
The string appears in the title | intitle:"index of" |
intext: |
The string appears in the body | intext:"password" |
filetype: / ext: |
Filters by file extension | filetype:pdf |
- |
Excludes a term | -www |
"..." |
Exact match | "internal use only" |
* |
Wildcard | site:*.target.com |
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
Replace target.com with the domain you have in scope. These are common patterns:
# 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
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.
# 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.
# 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.
Google isn't the only index. The same philosophy applies to:
org:targetorg filename:.env, "target.com" api_key). Developers upload secrets to repositories more than you'd think.I expand on these sources in the advanced recon techniques guide.
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).
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.
47 checks ordered by cost: first what can get you in trouble, then the cheap stuff, and finally the expensive stuff — which is where the big bounties are. I'll send it to your inbox right now.
Unsubscribe in one click, from any email.
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:
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.
A non-negotiable point. Searching with Google is legal, but acting on what you find isn't always:
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.
Dorks aren't an end in themselves: they're an early phase of reconnaissance. A typical flow:
url= parameter, a staging subdomain.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.
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.
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.
hunters training
labs from real hacks
completions
paid out for these bugs
Create your free account and practice on labs based on real hacks that paid out thousands of euros. The Academy is free forever.
No card · free Academy · cancel anytime
Learn to identify and exploit IDOR (Insecure Direct Object Reference) vulnerabilities in web applications. From the basics to writing effective reports.
Take your reconnaissance phase to the next level with advanced techniques for subdomain enumeration, JavaScript file analysis, GitHub dorking and automation.
Explore the most common techniques for attacking insecure JSON Web Token implementations: from the none algorithm to JKU/JWK injection.