115 DORKS · 9 CATEGORIES · AUTHORISED TARGETS ONLY
Google Dork Generator — 115 Recon Queries for Bug Bounty & Self-Audit
Build powerful recon queries to find exposed files, login panels, databases, API keys, and more. Use only on your own domains or authorised bug-bounty targets.
The Google Dork Generator builds targeted Google search queries that surface information attackers and defenders both need — exposed files, forgotten login panels, misconfigured cloud buckets, and sensitive data that shouldn't be publicly indexed. Pick a category, optionally enter a target domain, and the tool generates every dork in that category pre-formatted with site: restrictions. Click any dork to open Google in a new tab. Use the custom builder to chain your own operators. Everything happens client-side — no accounts, no rate-limits on generation itself (Google's own CAPTCHA is the limit that matters).
What is different about this tool: 115 curated dorks across 9 categories, all verified to return real results in 2026. Most online dork generators show 10-15 examples copied from a 2015 Exploit-DB dump, and most of those stopped working years ago because Google de-indexed the targets. This tool's catalogue is maintained actively — stale dorks retired, new ones added, with categories covering modern tech (cloud configs, docker-compose files, .env leaks, IoT panels). The custom builder supports 10 operators including exclusion (-inurl:, -site:) and exact-match phrases. Session history tracks what you've generated so you can copy whole batches into a report.
How it works under the hood
Every dork in the catalogue is a pre-formatted Google search query using the same advanced operators Google itself documents — site:, inurl:, intitle:, intext:, filetype:, and combinations. The tool does not query Google directly (that would hit CAPTCHA almost immediately). Instead, it builds the query string client-side and, when you click Search, opens Google in a new tab with the dork as the query parameter. You see Google's real search results — the tool is just the keyboard.
Category structure. The 115 dorks are split across 9 categories by target data type: Files (PDFs, Office documents, keys), Login Panels (admin, webmail, phpMyAdmin, Jenkins, GitLab), Directories (index-of listings, exposed .git/.svn), Databases (SQL dumps, sqlite files, phpMyAdmin instances), Config Files (.env, YAML, wp-config, docker-compose), Sensitive Data (SSH keys, log files with passwords, credential spreadsheets), Vulnerabilities (error messages indicating specific CVEs), Cloud (exposed S3/Azure/GCS buckets), and IoT (unsecured cameras, printers, industrial devices). Each category's dorks are independently effective — no prerequisite knowledge needed.
Target-domain restriction. When you enter a domain in the Target Domain field, every generated dork is automatically prefixed with site:yourdomain.com. This restricts results to that domain only — essential for bug-bounty work where you must stay within scope. Leave the field empty for untargeted dorks that find exposed resources anywhere on the web.
Custom builder. The builder lets you combine two operators per query, including exclusion operators (-inurl:, -site:, -intitle:) that narrow results by removing known-noise domains. A preview renders as you type so you can see exactly what Google will receive before you execute.
What this tool does not do. It doesn't scrape Google. It doesn't persist your queries to any server. It doesn't bypass Google's CAPTCHA (there's no way to — Google throttles query rate per IP). If you're running dorks at scale, pace yourself below ~20 searches per minute or use Google's Custom Search JSON API for legitimate high-volume needs. Automated scraping via residential proxies violates Google's Terms of Service, which is its own problem.
Five real-world use cases
Bug bounty reconnaissance on an in-scope target
You've just joined a bug-bounty programme and the scope includes `*.target.com`. Enter `target.com` as the domain, generate all 115 dorks, and work through them systematically. The high-value hits cluster in three categories: config files (exposed .env, wp-config, YAML with secrets), login panels (forgotten admin/staging/debug interfaces outside the main application), and directory listings (backup files, index-of pages that reveal deployment artefacts). Triage the findings against the programme's scope and severity rules before writing reports.
site:target.com filetype:env DB_PASSWORD
Self-audit: what has my own company accidentally exposed
The most important use case for anyone running infrastructure. Run the full 115-dork sweep against your own domain, prioritising config and sensitive-data categories. Expect to find things — every organisation does. Common surprises: a forgotten staging environment still indexed, a .git directory exposed behind a CDN miconfiguration, an old backup file in wp-content/uploads. Remove the content, rotate any exposed credentials, add noindex and robots.txt rules to prevent re-indexing, submit a Google search console removal request to flush the cache.
site:yourcompany.com intitle:"index of"
OSINT investigation of a person or entity
Journalism, due diligence, academic research, missing-person investigations — many legitimate OSINT workflows start with targeted Google dorks. Combine `site:` with `intext:` for a subject's name or email, `filetype:pdf` to find documents mentioning them, or `intitle:"index of"` to discover personal file shares. Respect privacy boundaries — OSINT is observation of publicly available information, not pretext for contacting or surveilling the subject. Document your methodology if the findings will be published.
intext:"john.doe@example.com" filetype:pdf
Phishing-infrastructure mapping during incident response
A phishing email targeting your organisation links to a domain. You want to map the attacker's broader infrastructure before takedown requests go out. Dork for distinctive strings from the phishing page (`intext:"specific brand copy"`), for subdomains of the phishing domain (`site:phishing-domain.com`), and for related exposed files (`filetype:html "login to your account"`). The goal is a full picture before the domain goes dark — so your takedown request covers the whole ring, not just one URL.
site:phishing-domain.com filetype:html
Security education — finding your own exposed API keys before attackers do
You're teaching a security class or running an internal awareness session. Run `site:github.com intext:"your-company-prefix" "api_key"` as a live demo — it will almost certainly find at least one developer's accidentally-committed key. Use the finding as a teaching moment: the same dork an attacker would run, on your own code, reveals the same exposure. This is how to make the abstract concept of 'secrets scanning' concrete for a team that has never seen it bite.
site:github.com intext:"companyname" "api_key"
Common mistakes & edge cases
Running dorks without checking scope or authorisation first
The dorks themselves are legal. What you do with results isn't necessarily. Bug-bounty programmes have explicit scope — domains in scope, out-of-scope, specific asset types allowed. Running dorks against out-of-scope targets and then reporting findings will get your account banned. For general research, stay on your own domain or on explicitly public-data targets. "I was just curious" has been a losing defence in multiple court cases.
Treating zero results as proof of nothing exposed
Google actively de-indexes sensitive content and rotates results. A clean sweep today doesn't mean the same dorks returned clean results last month or will tomorrow. If your self-audit returns nothing, re-run it monthly. For adversary-simulation purposes, cross-reference Google with Bing, DuckDuckGo, and Yandex — they index differently and sometimes return results Google has suppressed.
Saving or modifying content found via a dork
Clicking a dork result and viewing the page is one thing. Downloading exposed private keys, submitting credentials to a login panel you shouldn't have access to, or modifying any discovered resource turns passive observation into active intrusion — and changes the legal calculus completely. Observe the existence of the exposure, take a screenshot of the URL and timestamp, then leave. Report. Don't touch.
Expecting old GHDB dorks to work verbatim
Many dorks from the Google Hacking Database's early years no longer return results. Google's algorithm, combined with widespread SEO-induced cleanup of the index, has retired most of the classic dorks. Use old GHDB entries as creative prompts to modify, not as queries to run directly. Modern dorks target current-technology stacks — .env files, YAML configs, docker-compose files, cloud-specific patterns — which older catalogues underrepresent.
Getting CAPTCHA-blocked mid-assessment
Google throttles high-volume search traffic from single IPs. If you're batch-generating dorks and searching each one back-to-back, expect a CAPTCHA after ~20–30 queries. Work around this by pacing yourself (one dork per 30 seconds), using the Google Custom Search JSON API if you have real budget, or spreading queries across multiple days. Attempting to defeat the CAPTCHA (residential proxies, scraping services) often crosses Google's Terms of Service — a separate legal issue.
Reporting every dork hit as a vulnerability
Not every exposed file is a security issue. A company's marketing-brochure PDF showing up in `filetype:pdf site:company.com` is intentional publication, not exposure. Before reporting, ask three questions: (1) Was this content intended to be public? (2) Does it contain data that would harm the organisation if widely known? (3) Can an attacker do meaningful damage with this? If any answer is no, it's not a report — it's noise. Bug-bounty triagers reject noisy reports fast and your reputation on the platform suffers.
Frequently Asked Questions
Using Google search operators is completely legal everywhere we're aware of. Google dorking is just Google search with advanced syntax. What crosses legal lines is what you do with the results — accessing systems, downloading data, or interacting with discovered resources without authorisation violates computer-fraud laws in most jurisdictions. Dorking on your own domain, on bug-bounty in-scope targets, or for general awareness is all legal and routine.
Yes — Google dorking is one of the most common recon techniques in bug bounty programmes. Use the `site:` operator with your in-scope target domain to discover forgotten admin panels, exposed backup files, leaked API keys, and debug pages. The results are starting points for further testing under the programme's rules. Always verify your target is in scope before running any dork.
Several reasons. Google actively removes sensitive results from search (SafeSearch and manual action both apply). Site owners can block indexing via robots.txt or noindex directives. Content may have been removed since it was indexed. And Google's algorithm rotates results for identical queries — the same dork run twice an hour apart can return different results. If a dork returns nothing, try the next one in the same category rather than assuming the target is clean.
Enter the target domain in the 'Target domain' field at the top of the tool. Every dork generated is automatically prefixed with `site:domain.com`, restricting results to that domain only. Leave the field empty to get untargeted dorks that find exposed resources anywhere on the web.
They are functionally near-identical. `filetype:` is the older operator; `ext:` is a newer alternative that Google introduced as a cleaner syntax. Both match the file extension at the end of a URL. In practice, the results overlap almost entirely — if one returns nothing useful, try the other as a variation.
Dorks targeting credentials and private keys carry the highest impact. `filetype:env DB_PASSWORD` surfaces exposed .env files with database passwords. `intitle:"index of" id_rsa` finds exposed SSH private keys. `filetype:log intext:password` exposes log files containing cleartext passwords. These findings in your own infrastructure are emergencies — rotate credentials and remove the content immediately. In authorised bug-bounty work, they typically earn the highest payouts.
Yes — sending many dork queries rapidly from the same IP triggers Google's CAPTCHA (anti-bot) challenges and, at higher volumes, temporary IP blocks. This tool generates dorks client-side and sends you to Google one at a time via your own browser, which looks like normal usage. If you're dorking at scale, pace yourself to stay under rate limits or use Google's Custom Search JSON API (paid, higher limits).
Selectively. Exploit-DB's GHDB contains thousands of historical dorks, but most have been de-indexed by Google over the years as privacy and abuse mitigations improved. The dorks in this tool's 115-query catalogue are curated for current-year effectiveness — all verified to return real results in 2026. Browse GHDB for research, but treat old dorks as leads to modify rather than queries to run verbatim.
Responsible disclosure depends on what you found and where. If it's on a domain in a bug-bounty programme, follow that programme's reporting process. If it's a clear security issue on a general company's domain, their security.txt file or security@domain email is the right contact — send a concise write-up with the specific dork and a screenshot. Never download, modify, or persist with the resource after initial discovery. Report, then walk away.
Yes. The 115 dorks in this tool are curated for current effectiveness, not copy-pasted from ten-year-old lists. Categories including config files (.env, yaml, json with secrets), cloud (exposed S3 buckets), IoT (unsecured cameras), and login panels get particular attention because they surface high-impact findings that Google hasn't successfully de-indexed yet. The catalogue is reviewed periodically — stale dorks are retired, new ones added.