Google Hacking: Advanced Search Operators and the GHDB, Used Safely

Key takeaways

• The main operators are site:, filetype:, intitle:, inurl:, intext:, OR and the minus sign.
• Use dorks to audit your own domain first; testing anyone else's needs written authorisation under India's IT Act.
• robots.txt does not protect a file. Remove it, require login, or use noindex.
• Google has retired the cache: operator; the Wayback Machine serves old copies.

What is Google hacking?

Google hacking, also called Google dorking, means using Google's advanced search operators to find information that a site owner exposed by mistake: forgotten backup files, configuration files, directory listings, admin login pages. Nothing is broken into. Google simply indexed pages that were public. That is exactly why defenders use the technique first, on their own domains, before someone else does.

Legal note. Running a search is not an offence. Opening, downloading or using sensitive data you find that belongs to someone else, or probing a site you have no permission to test, can be an offence under India's IT Act, 2000. In an engagement, get written authorisation that names the domains in scope. If you find exposed data on a site that is not yours, report it to the owner, or to CERT-In, and do not browse further.

The operators you need to know

These are the core operators. Each example uses a placeholder domain, example.com. Replace it with a domain you own or are authorised to assess.

Google has retired cached page links and the cache: operator, so do not rely on it. To see an older copy of a page, use the Internet Archive's Wayback Machine instead. Operator behaviour changes without notice, so test any query before you build a process on it.

How to audit your own site step by step

1. Start broad. Search site:yourdomain.com and note how many pages Google shows. If it is far more than you expected, you may have staging pages, old uploads or parameters being indexed.
2. Look for documents. Run site:yourdomain.com filetype:pdf, then repeat for xlsx, docx, csv, txt, log, sql, bak. Open each unexpected hit. Check whether it should be public.
3. Look for directory listings. Try site:yourdomain.com intitle:"index of". A hit means a web server is listing folder contents.
4. Look for admin and login pages. site:yourdomain.com inurl:login and inurl:admin. A login page being public is normal; an admin console reachable from the whole internet with no extra protection is a finding.
5. Look for debug and config leftovers. Try inurl:phpinfo and ext:env, ext:ini, ext:conf limited to your site. These should return nothing.
6. Record and fix. Write down URL, what it exposes and who owns it. Fix the cause (below), then request removal from Google if needed.

The Google Hacking Database

The Google Hacking Database (GHDB), maintained by OffSec alongside Exploit-DB, is a catalogue of dorks grouped by what they find, such as footholds, files containing usernames, sensitive directories and vulnerable servers. Defenders use it as a checklist. Take the categories relevant to your technology stack, add your own site: restriction, and run them against your domain. Do not run them unrestricted to hunt for victims; that is not testing, it is trespass.

How to fix what you find

• Remove or protect the file. Delete it from the server, or put it behind authentication. This is the real fix.
• Do not rely on robots.txt. It is a polite request to crawlers, it is itself public, and it can reveal the very paths you wanted hidden. A blocked URL can still appear in results if other pages link to it.
• Use noindex for pages that must be reachable but not listed. Google's Search Central documentation explains the noindex meta tag and header, and the Removals tool in Search Console for urgent cases.
• Turn off directory listing. In Apache, Options -Indexes; in Nginx, make sure autoindex is off.
• Rotate anything that leaked. If a password, key or token was ever public, assume it was copied. Change it, do not just hide the file.
• Keep backups and uploads outside the web root.

Common mistakes

• Believing a long, unlinked URL is private. Crawlers find URLs through sitemaps, referrers and links in other pages.
• Hiding a file with robots.txt and calling it done.
• Treating one clean run as permanent. Rerun the audit after each major release.
• Testing a client's domain before the scope document is signed.

Where this fits in your career

Dorking is a passive footprinting step, the first phase of the CEH syllabus and of most reconnaissance work in penetration tests and OSINT investigations. It costs nothing, so employers expect you to know it, and it teaches an important lesson: a surprising share of breaches begin with data that was never meant to be public.

Next steps

To practise footprinting within a legal, supervised syllabus, see WebAsha's CEH v13 AI course. For related reading, try the GHDB guide and Google dorking for footprinting.