• Posted by: Eng. Donya Bino
• February 06, 2026

Google Dorking in Reconnaissance

Google Dorking (also called Google Hacking) is the technique of using advanced search operators in Google (and sometimes Bing or other engines) to find publicly exposed information that organizations never intended to be indexed, login pages, sensitive files, configuration data, error messages leaking database details, unsecured admin panels, backups, API keys, and much more.

It is almost always the first step in real-world reconnaissance because it is:
1. completely passive (no packets sent to the target)
2. free and extremely fast
3. very effective against misconfigured or forgotten assets
4. almost impossible to detect from the target's side

Even in 2025–2026, with better security awareness and WAFs, companies still leak sensitive data through Google every day.

The following operators are the most useful when searching for files and information on Google. 
1. site: - This operator allows you to search within one domain using example: site:example.com
2. inurl: - This operator will require the specified word to appear in the URL ie: inurl:admin/ login
3. intitle: - This operator requires the specified word to appear in the title of the page ie: intitle:index of
4. filetype or ext: - This operator will require you to restrict the results based on the file extension ie: filetype:pdf/ or ext:doc
5. intext: - Will require the specified word to be contained in the page body ie: intext: password 
6. " " - Use of quotation marks will search for an exact phrase ie: index of /
7. - - The dash symbol allows the exclusion of a specified keyword example: -inurl (login | sign up)
8. cache: - Allows you to see Google's cached version of any page example: cache:example.com/admin

Examples of practical and high-impact uses for google dorking:
Accessing exposed directories and backups
1. intitle:index of (parent directory)
2. intitle:index of (backup | bak | cache | old | db | sql)
3. filetype:sql “MySQL dump” (pass | password | pwd)
4. filetype:env “DB_PASSWORD” | “DB_USERNAME” | "SECRET_KEY" 

Accessing login and admin pages 
1. inurl:admin | inurl:login | inurl:cpanel | inurl:webmail
2. intitle: (admin login | control panel | dashboard) -inurl:(Signup).
3. inurl:phpmyadmin | inurl:adminer | inurl:pma 

Accessing sensitive documents/files
1. filetype:pdf intext:(Confidential | Internal Use Only)
2. filetype:xls | filetype:xlsx intext: (password | username).
3. filetype:log intext: (Error | Exception | Password).

Vulnerable Software Footprints
1. intext:"phpMyAdmin" "running on"
2. inurl:elmah.axd (exposed error logs)
3. intext:"powered by wordpress" inurl:wp-config.php
4. inurl:".git/HEAD"

Error Message Leaks
1. intext:"SQL syntax near" OR intext:"mysql_fetch" OR intext:"ORA-01756"
2. intext:"Warning: mysql_connect()" OR intext:"Uncaught PDOException"

Examples of Real-World Scenarios
Scenario 1: A Small Business Having Backups Available Publically using Google. Example: Dork- site:companyname.com intitle:index of, backup Result- It Showed an Open Directory for Backups Including a Database Backup 2024 Filename of "database_backup_2024.sql.gz",which Contained All Customer Information Such as Customer Name, Customer Email Address, Hashed Passwords, and Partial Payment Card Data. They Downloaded the Entire Database Dump and Sold Those Records On the Dark Web To Conduct Credential Stuff Attacks On the Customers Themselves.

Scenario 2: An Educational Institution Business Have An Exposed Administrative Panel Using Google. Example: Dork Site: Unversity.edu inurl=admin/or inurl=cpanel Result= Exposed PhpMyAdmin Login Page using
Default Usernames/Passwords. The Attacker was Able To Login, To Dump The Students Database and Commence Identity Theft And Extortion.

Scenario 3: An e-commerce website experienced configuration file leaks. The attacker used the search “dork: site: shopname.com filetype: env “DB_PASSWORD”” to locate an exposed .env file containing database login credentials, API keys, and secret salts. The attacker was able to access the production database for the e-commerce store, use the credentials to steal customer information, and subsequently create fraudulent orders and chargebacks.

Scenario 4: The attacker used the search term “dork: intext:”SQL syntax near” site: company.com” to find a full SQL query (including table names) that was generated by a web application. The attacker took the SQL query and created an SQL injection exploit so they could execute the exploit and gain complete access to the company’s database.

How to Safeguard Your Website with Practical Steps
1. Search your website weekly (using your site domain and a list of dangerous keywords) to see if there are any "dorks" that may expose vulnerabilities that you didn't realize existed

2. Disable directory listing on your web server (Apache: use Options -Indexes in your .htaccess file or httpd.conf file)

3. Remove all unnecessary files from your web server (e.g., backups, .env files, config files, test pages).

4. Use robots.txt file to block sensitive directories or pages from being indexed by search engines (NOTE: attackers do not follow the robot.txt standard).

5. Use a web application firewall (WAF) to protect your website against attackers (e.g., Cloudflare's free tier blocks many reconnaissance dorks and commonly used exploitation patterns).

6. Hide the server banner on your web server (Apache: ServerTokens Prod and ServerSignature Off within respective configuration files).

7. Monitor Google for the indexing of sensitive keywords associated with your domain (i.e., set up a Google Alert for each of the sensitive keywords on your website).

Key Takeaways
Google Dorking remains one of the fastest, cheapest, and most effective reconnaissance techniques because organizations continue to expose sensitive files, admin panels, backups, configs, and error messages to public search engines. Attackers don’t need zero-days when you leave the front door open.

Do this today: Open Google → type site:yourdomain.com + backup | env | admin | password | sql If anything sensitive appears → remove it immediately and harden your server.