10 Google Dorks You Should Know About

I keep coming back to Google dorking in conversations with people new to security research because it’s one of the rare techniques that requires zero tooling, zero cost, and teaches you an enormous amount about how the web actually works under the hood. You don’t need a lab environment or a license — just a search bar and an understanding of a dozen operators. Here are ten of the most useful and widely referenced dorks, what they’re used for, and how to use this knowledge responsibly.

A note before we start: every example here is meant for authorized security testing, auditing your own assets, or general education about how information becomes unintentionally exposed. Using these against systems you don’t own or have permission to test can cross legal lines depending on what you do with anything you find.

Quick Refresher: The Operators Behind These Dorks

The 10 Dorks

1. Exposed Directory Listings

intitle:"index of" "parent directory"

This finds open web directories where a server is listing its entire folder structure instead of serving a proper homepage — often revealing files never meant to be browsable, from documents to backups.

2. Login Portals

inurl:admin intitle:login

Surfaces indexed administrative login pages. On its own this isn’t a vulnerability — it just tells you an admin panel exists and is reachable, which is useful reconnaissance for an authorized penetration test assessing attack surface.

3. Configuration and Environment Files

filetype:env "DB_PASSWORD"

Searches for exposed .env files that sometimes contain database credentials, API keys, or other secrets accidentally deployed to a public web root.

4. Exposed SQL Database Files

filetype:sql "INSERT INTO" intext:password

Looks for publicly accessible SQL dump files that may contain database schemas and, in poorly secured cases, actual user data.

5. Publicly Indexed Spreadsheets with Sensitive Data

filetype:xls OR filetype:xlsx intext:"confidential"

Finds spreadsheets marked confidential that were nonetheless indexed — a common finding in internal document leaks caused by improper sharing settings on cloud storage.

6. Exposed Log Files

filetype:log intext:"error" OR intext:"password"

Application and server log files can sometimes end up in web-accessible directories, occasionally containing session tokens, internal IPs, or other operationally sensitive details.

7. Government and Corporate PDFs Marked Sensitive

site:gov filetype:pdf intext:"internal use only"

A pattern often used in OSINT investigations and journalism to find sensitive but publicly indexed government documents — illustrating how classification markings don’t prevent indexing if access controls weren’t properly applied.

8. Exposed Git Repositories

intitle:"index of" ".git"

An exposed .git directory can allow reconstruction of an application’s full commit history and source code, including any secrets that were ever committed — even if later removed, since git history retains old commits.

9. Camera and IoT Device Dashboards

intitle:"webcamXP" OR intitle:"live view" inurl:"view/index.shtml"

Certain camera and IoT device web interfaces use predictable page titles and URL patterns, making them discoverable when left on default configurations without authentication. This category is frequently referenced in IoT security awareness training as a reminder to change default credentials and disable unnecessary remote access.

10. Cached Pages Revealing Removed Content

cache:example.com/sensitive-page

Even after a page is taken down from a live site, Google’s cache (where still available) can sometimes retain a snapshot of previously exposed content, which is a useful check when verifying that a remediation was fully effective.

How These Fit Into a Recon Workflow

flowchart TD
    A[Authorized scope confirmed] --> B[Run targeted dork queries]
    B --> C[Catalog findings by exposure type]
    C --> D{Sensitive data found?}
    D -- Yes --> E[Do not access/download - document only]
    D -- No --> F[Note as clean, move to next target]
    E --> G[Report to asset owner for remediation]
    G --> H[Verify fix and re-check indexing status]

Comparison: Risk Level of Common Dork Categories

Real-World Relevance

Security researchers and bug bounty hunters use exactly these categories of queries as a standard part of reconnaissance during authorized engagements, often citing the Google Hacking Database (GHDB) — maintained under Offensive Security’s Exploit-DB — as their reference library. The GHDB currently catalogs thousands of dorks contributed by the research community, organized by category (footholds, sensitive files, vulnerable servers, and more), and remains one of the most cited public resources in OSINT methodology write-ups.

Defensive Takeaways for Each Dork

• Directory listings: Disable directory browsing at the web server configuration level.
• Login portals: Not inherently risky, but pair with rate limiting and MFA.
• Config/env files: Never deploy .env or config files to public web roots; use environment variables or secrets managers instead.
• SQL dumps: Store backups outside the web root, ideally in access-controlled, non-public storage.
• Sensitive spreadsheets: Audit cloud sharing settings regularly; default to “restricted” access.
• Log files: Store logs outside publicly accessible paths and scrub sensitive data before persisting.
• Marked-sensitive documents: Apply actual access controls, not just a “confidential” label.
• Exposed .git: Ensure .git directories are excluded from deployment artifacts and blocked at the web server level.
• IoT/camera dashboards: Change default credentials, disable unnecessary remote/public access, and place devices behind a VPN where possible.
• Cached content: After remediating an exposure, request removal via Google Search Console rather than assuming the cache will clear on its own.

Common Mistakes When Using These Techniques

1. Running these queries against domains you don’t have explicit authorization to test.
2. Downloading or storing sensitive data found through a dork “to prove the finding” — documentation of the exposure (URL, screenshot of a non-sensitive portion) is usually sufficient.
3. Assuming a dork returning no results means an organization has no exposure — Google’s index isn’t exhaustive or perfectly current.
4. Forgetting to re-verify after remediation, since delayed re-crawling can leave stale cached results visible temporarily.

FAQs

Are these dorks still effective today? Many classic patterns still work, though Google has made some changes over the years (like limiting the link: operator), and organizations have generally gotten better about basic exposures like open directory listings, though config file and cloud storage exposures remain very common.

Can I get in trouble just for running these searches? Running a search query itself is generally legal, but accessing, downloading, or misusing any sensitive data you find without authorization can create legal exposure depending on your jurisdiction and what you do with the findings.

Is there a tool that automates dork searching? Yes, various OSINT and reconnaissance tools can automate querying against the GHDB’s catalog of dorks, though manual, targeted queries are often more precise for a specific authorized engagement.

Where can I learn more dorks? The Google Hacking Database (GHDB) is the most comprehensive and actively maintained public resource, categorized by exposure type.

Summary and Recommendations

These ten dorks represent some of the most common and instructive patterns in the Google Hacking Database — useful both for understanding how attackers find low-hanging fruit and for auditing your own organization’s exposure before someone else does. Used responsibly and within authorized scope, they remain one of the most accessible entry points into practical security reconnaissance.

For further reading:

• Google Hacking Database (Exploit-DB): https://www.exploit-db.com/google-hacking-database
• OWASP Testing Guide: https://owasp.org/www-project-web-security-testing-guide/
• Google Search Console: https://search.google.com/search-console/about
• MITRE ATT&CK – Search Open Websites/Domains: https://attack.mitre.org/techniques/T1593/