Search Engine Dorking: Google, GitHub & Beyond

Search engines have already crawled and indexed an enormous slice of a target's exposed content, login pages, PDFs, config files someone left public, forgotten subdomains, even leaked credentials. Dorking (also called Google hacking) is the art of writing a precise query that filters that giant index down to exactly what you want. The last lesson showed how crawlers build the index; this one is how you interrogate it.

The best part for a beginner: it's all done from a normal search box, it's completely passive (you never touch the target), and the only skill is asking a sharper question.

The highest-leverage recon is usually not "more tools", it's a better question, encoded as search operators.

The core operators

A dork is just ordinary search plus a handful of operators. These few carry almost all the weight:

The power comes from stacking them. Each operator narrows the result set, so a good dork is a chain of them describing precisely the thing you suspect exists.

Recon dorks that pay off

Entry points: normal pages, logins & signups

site:*.hackingpath.com -www -support -docs           # every subdomain except the boring ones
site:hackingpath.com inurl:/products                 # a normal application path
site:hackingpath.com inurl:login | inurl:signin | inurl:signup | inurl:admin   # auth & internal pages

That middle dork, inurl:/products, is just a sample path: swap it for any route you suspect exists. The third one hunts login and signup pages, an internal admin login that was never meant to be indexed is a classic find.

Find exposed files and leaks

site:hackingpath.com inurl:test.php | ext:php        # forgotten test/debug scripts (test.php)
site:hackingpath.com ext:env | ext:bak | ext:sql | ext:conf | ext:log   # config & data leaks (.env, backups)
site:hackingpath.com intext:"BEGIN RSA PRIVATE KEY"  # an exposed private key file (id_rsa)
site:hackingpath.com intitle:"index of" backup | .git | uploads         # browsable directories

Three file finds worth memorising: a stray test.php (often left over from debugging and full of phpinfo() detail), an .env file (application secrets, DB passwords, API keys), and an exposed RSA private key (id_rsa), any one of these can hand an attacker the keys to the kingdom, and the crawler indexed them because someone published them without thinking.

Find sensitive functionality

site:hackingpath.com inurl:redirect= | inurl:url= | inurl:next=    # open-redirect / SSRF candidates
site:hackingpath.com inurl:upload | inurl:file | inurl:attachment  # upload points

The community-maintained Google Hacking Database (GHDB) at exploit-db.com catalogues thousands of ready-made dorks for exposed cameras, printers, dashboards, login portals, and more, a great place to learn patterns.

The same idea, other engines

Google has the deepest index, but a page Google dropped may still live in another engine. Cross-checking is a cheap win:

• Bing , unique operators like ip: (find sites on a shared IP) and feed:.
• Yandex , fine-grained control with host:, mime:, domain:; often indexes things others miss.
• DuckDuckGo , privacy-friendly, plus !bang shortcuts (!g Google, !gh GitHub) to pivot fast.

Also worth dorking: SaaS tools where staff leak internal docs and tickets. The pattern is site:<the-saas-platform> "<your-target>", and it works against any organisation's public footprint:

site:*.atlassian.net "hackingpath.com"     # leaked Jira / Confluence pages
site:docs.google.com "sony.com"            # public Google Docs mentioning the target
site:groups.google.com "google.com"        # public mailing-list threads
site:pastebin.com "hackingpath.com"        # pastes and dumps referencing the target

GitHub dorking: hunting secrets in code

Developers commit secrets to public repositories constantly. GitHub's own search, with operators, finds them:

org:hackingpath filename:.env               # committed environment files
org:hackingpath AWS_SECRET_ACCESS_KEY       # cloud keys
org:hackingpath DB_PASSWORD | DATABASE_URL  # database creds
org:hackingpath sk_live_                    # live Stripe keys

Operators here: org:, filename:, extension:, language:. Tools like GitDorker and truffleHog automate the sweep, but the manual query teaches you what to look for.

A simple workflow

1. Confirm scope , only dork targets you're authorised to assess.
2. Nail the names , the exact domains and organisation names to plug into site: and org:.
3. Run a baseline set , subdomains, login panels, then exposed files.
4. Pivot engines , re-run key dorks on Bing and Yandex.
5. GitHub sweep , org: plus secret patterns.
6. Triage , validate each hit, note what's actually sensitive.

The one rule that matters

Dorking itself is passive and legal: you're querying a search engine's stored copy, not the target's servers, so nothing touches the target and no one sees you looking. But acting on a find is different. Opening an exposed admin panel, downloading a leaked database, or using a found credential can be well outside your authorisation. Find freely; only touch what you're in scope to touch.

Try it (terminal)

The lab beside this lesson has a small search index you can query with a google command. Craft the dork that surfaces the exposed file, then retrieve it.

1. google "site:hackingpath.com" , broad, lots of noise.
2. google "site:hackingpath.com ext:env" , narrow to the leaked config file.
3. curl the URL the dork returns, and read what was left exposed.

Why this matters

Half of real bug-bounty and pentest wins start not with an exploit but with a search: a forgotten .env, a public backup, a leaked key, an admin panel that was only ever "hidden" by not being linked. Learn to encode a hunch as a dork, and the target's own carelessness, indexed and waiting, does half your work for you.