Google dorks for defenders: finding your exposed assets before attackers do

Originally published in 2013 when this blog covered offensive tutorials; rewritten in 2026 with a defensive focus.

The original post taught "Google hacking" — using advanced search operators to find exposed cameras, confidential documents, and login pages, with examples tuned for snooping on strangers' infrastructure. The technique itself isn't criminal, but the direction matters. This rewrite points the same search power at the only legitimate target: your own organization's exposure.

What Google dorks are (and why defenders should know them)

Attackers routinely use operators like site:, filetype:, intitle:, and inurl: to locate misconfigured assets indexed by search engines: exposed admin panels, backup files, unprotected documents, even open webcams. If it's indexed, assume attackers have already searched for it. Defenders should run these same queries against their own domains to see what the internet sees.

A defensive dork audit for your own domain

Run these against domains you own or are authorized to assess, then fix whatever turns up:

site:yourdomain.com filetype:pdf confidential — internal documents that leaked into the index.
site:yourdomain.com intitle:"index of" — directory listings exposing file trees.
site:yourdomain.com inurl:admin — admin and login interfaces visible to the public.
site:yourdomain.com filetype:sql OR filetype:bak OR filetype:env — database dumps, backups, and config files that should never be web-accessible.
site:yourdomain.com inurl:webcam OR intitle:"live view" — cameras or monitoring pages accidentally exposed.

What to do with what you find

Remove or restrict it: take down exposed files, require authentication, and block directory listings.
De-index it: use robots.txt, noindex meta tags, and Google's removal tools so the exposure doesn't persist in the cache.
Check access logs to see whether anyone retrieved the exposed content before you closed it — that determines whether this is a cleanup or an incident.
Automate the audit: schedule recurring external-attack-surface scans so new exposures get caught at deployment time, not months later.

Where the line is

Searching your own assets is good hygiene. Running the same operators against someone else's infrastructure to find exploitable openings is reconnaissance — and acting on it without authorization is illegal. The 2013 version of this post blurred that line with its examples; this one draws it clearly.

Authorization disclaimer

All security testing must only be done on systems you own or are explicitly authorized to assess. Use dorking to audit your own exposure; never use it to map or probe someone else's.