Search engines have already crawled much of the internet for you. Using Google dorks for bug bounty recon means asking Google precise questions about your target, so it shows you pages, files and subdomains you might never find by clicking around. It needs no special tools, makes no requests to the target, and often turns up forgotten corners of an application. In this guide I’ll cover the operators that matter, how I combine them, and how to keep the results useful.
What a Google dork is
A “dork” is just a search query that uses advanced operators. Instead of searching for words, you filter by domain, URL, page title or file type. Because the search engine is doing the crawling, dorking is passive: you are reading Google’s index, not touching the target’s servers.
That makes it a natural part of the passive phase of recon, alongside OSINT techniques for bug bounty and subdomain enumeration. Of course, anything you find still has to be in scope before you test it. Check the program’s scope and rules first.
The operators you will actually use
site:limits results to a domain and its subdomains.site:example.com-site:removes a domain.site:example.com -site:www.example.cominurl:the word must appear in the URL.inurl:adminintitle:the word must appear in the page title.intitle:"index of"intext:the word must appear in the page body.filetype:orext:limits to a file extension.ext:pdf"exact phrase"matches the words in that order.OR(in capitals) and brackets group alternatives.(ext:log OR ext:txt)-wordexcludes results containing a word.
Google changes how strictly it honours some operators, so if a query returns nothing, simplify it and try again.
Google dorks for bug bounty: a practical set
Always start every query with site:example.com (replaced with your in-scope domain). That keeps the results on your target and nowhere else.
1. Find subdomains
site:*.example.com -site:www.example.comKeep adding -site: for each subdomain you have already seen. The list gets shorter and the rare hosts rise to the top.
2. Find login and admin areas
site:example.com (inurl:login OR inurl:signin OR inurl:admin OR inurl:dashboard)These pages show you where authentication lives and which internal tools might be exposed.
3. Find documents
site:example.com (ext:pdf OR ext:doc OR ext:docx OR ext:xls OR ext:xlsx OR ext:ppt)Public documents often reveal internal hostnames, software names, username formats and old product names that help the rest of your recon.
4. Find directory listings
site:example.com intitle:"index of"An open directory listing on an in-scope host is worth a closer look, both as a finding in its own right (if the program accepts it) and for what the files reveal.
5. Find API documentation and endpoints
site:example.com (inurl:api OR inurl:swagger OR inurl:graphql OR inurl:openapi)Swagger or OpenAPI pages list endpoints and parameters in one place, which saves hours of manual mapping.
6. Find error pages and debug output
site:example.com (intext:"stack trace" OR intext:"warning:" OR intext:"exception")Errors reveal frameworks, file paths and versions. They tell you what the application is built with.
7. Find old and staging environments
site:example.com (inurl:dev OR inurl:staging OR inurl:test OR inurl:old OR inurl:beta)Non-production hosts are often less hardened than the main site. Confirm they are in scope before testing.
8. Find interesting parameters
site:example.com (inurl:redirect= OR inurl:url= OR inurl:next= OR inurl:return=)URL parameters that take another URL are classic places to test for open redirects and SSRF, once you are sure the host is in scope.
Beyond Google
Different search engines index different pages. Bing supports similar operators (site:, inurl:, filetype:), and DuckDuckGo works for simple site: queries. Running your best dorks on more than one engine often finds extra results.
Code and document platforms are worth searching too. Try site:github.com "example.com" for public repositories that mention your target, or site:trello.com "example.com" for public boards. Treat anything sensitive you find there carefully: report it, don’t use it.
Making dorking efficient
Doing this by hand works, but a few habits make it faster:
- Keep a dork list. Save your best queries in a text file with
example.comas a placeholder, then replace it for each new target. - Use a short delay. If you search too fast, Google shows a CAPTCHA. Space your searches out. Don’t try to bypass the CAPTCHA.
- Save results as you go. Copy interesting URLs into your notes with the dork that found them. You will want to know later where a URL came from.
- Feed results into other tools. New subdomains go into your probing step, and new URLs go into your list for content discovery.
A simple way to probe the hosts you collected:
# hosts-from-dorks.txt contains one hostname per line
httpx -l hosts-from-dorks.txt -silent -status-code -titleCommon mistakes with Google dorks
- Forgetting
site:. Without it, you are searching the whole internet, and you might end up looking at systems that have nothing to do with your program. - Reporting the search result instead of the bug. “Google shows this page” is not a vulnerability. Show the real impact of what is exposed.
- Trusting old results. Google’s index can be out of date. Always check that the page still exists before you write anything.
- Downloading sensitive files. If a result looks like it contains personal data or credentials, don’t open more than you need to confirm it. Report it.
- Stopping at Google. Combine dorks with archives, certificate logs and active enumeration for a complete picture.
Conclusion
Google dorks for bug bounty are free, passive and surprisingly powerful. A handful of well-built queries can show you subdomains, documents, admin panels, API docs and old environments in minutes. Keep them scoped with site:, save what you find, and feed it into the rest of your recon workflow.
If you want a complete, repeatable recon process that includes passive sources like these, have a look at the Medium Scope Reconnaissance ebook, or join the waitlist for the Medium Scope Reconnaissance course.
