Google Dorking: Finding Exposed Files and Panels

Google dorking is the practice of using advanced search operators to find pages, files, and panels that are sitting in Google's public index even though their owners never meant them to be found. No scanner, no payload, nothing touching the target server: you are just asking the world's biggest crawler to show you what it already collected. For a recon phase that is a gift, because a search engine has often done the enumeration for you and filed it under a few well chosen keywords.

This guide builds up from what the operators do, to how you chain them into real findings, to the Google Hacking Database as a ready made catalog, and finally to the defender side, since the fix for an indexed secret is rarely the one people reach for first. Read it start to finish once, then keep it as a cheat sheet.

01What Google dorking is

Google dorking, sometimes called Google hacking, is ordinary searching with the operators turned all the way up. The term goes back to Johnny Long in the early 2000s, who noticed that a short search string could reliably surface things like exposed webcams, config files, and backup dumps across the whole internet at once. A "dork" is just one of those crafted queries. You type it into the same search box everyone uses, and Google answers from its existing index.

The power comes from precision. A plain search for "login" returns a billion pages of noise. A dork pins the search to one site, one file extension, one phrase in the title, and suddenly the result set is five pages that all look like forgotten admin portals. You are not finding new vulnerabilities, you are finding what was already published by mistake and reading it back with a sharper lens.

02Why search engines index what owners meant to hide

Search engines index unintended content because crawling is automatic and nobody told the crawler to stop. Googlebot follows links, reads sitemaps, and picks up URLs from referrals and from other indexed pages. If a file is reachable over HTTP and something, anywhere, points at it, it can end up in the index. The owner usually never decided to publish it. They dropped a backup in the web root, left directory listing on, or linked a staging panel from a public page, and the crawler did the rest.

The loop below is the whole problem in one picture. A file becomes reachable, the crawler finds and stores it, and from then on a single query pulls it back out.

Reading a site's own robots.txt is the fastest way to see what the owner tried to keep out of search, because the disallowed paths are a map of where they think the sensitive content lives. That file is public by design, so fetching it touches nothing you should not touch.

$ curl -s https://example.com/robots.txt
User-agent: *
Disallow: /admin/
Disallow: /backup/
Disallow: /private-uploads/

03The core search operators

The core operators each narrow the result set along one axis, and you combine them to cut to exactly what you want. Five of them carry almost every dork, plus the minus sign to throw results away. Learn these six and you can read most of the dorks you will ever see.

# each operator on its own, run against your own domain first
site:example.com                 the pages Google has indexed for one site
inurl:admin                      "admin" somewhere in the URL path
intitle:"index of"               Apache-style directory listing titles
intext:"sql syntax"              an error string leaking from the body
filetype:env                     served files with a .env extension
site:example.com -www            the same site, minus the www host

The quoted string in intitle:"index of" matters: quotes force an exact phrase, so the two words have to appear together and in order. Without quotes Google is free to treat them as loose keywords and the precision falls apart.

04Combining and refining to sharpen the hit

Combining operators is where dorking stops being a parlor trick and starts returning real findings, because each operator you add removes a whole category of noise. Stack them and the engine treats them as AND by default, so every result must satisfy all of them at once. A few extra syntax pieces round out the toolkit.

The mental model is a funnel. You start broad with one axis, then add axes until the result set is small enough to read by hand. The diagram shows a typical narrowing from a whole domain down to a single exposed file type carrying one keyword.

# 0xpriv.dev/recon
# the same intent, widened then tightened
site:example.com filetype:sql                    any indexed SQL file on the site
site:example.com filetype:sql intext:"INSERT INTO"   dumps that actually contain rows
site:example.com (filetype:sql OR filetype:bak)  two backup formats in one query
site:example.com intitle:"index of" "parent directory"   browsable folders only

05Finding login panels and admin interfaces

Login panels are one of the easiest things to surface, because authentication pages announce themselves in their title and URL. Administrators move panels to odd paths for safety, but the page title still says "Login" and the URL still says "admin", so a title or URL dork walks right up to them. The point on an authorized test is inventory: knowing which panels are reachable from the internet before you decide what is in scope.

site:example.com inurl:login
site:example.com inurl:admin intitle:login
site:example.com (intitle:"sign in" OR intitle:"log in")
site:example.com intitle:"phpMyAdmin" intext:"Welcome to phpMyAdmin"
site:example.com inurl:/wp-admin/

Watch for panels that should never face the public: database managers like phpMyAdmin or Adminer, router and camera dashboards, CI and monitoring consoles, and staging copies of the real app. Each one is a note in your recon log, not an invitation to log in.

06Config files, backups, and directory listings

Config and backup files are the prize, because they often carry credentials, keys, and connection strings in plain text. Developers leave an .env in the web root, zip the site before an update and forget the archive, or let the server list a directory the moment there is no index page. Each habit has a reliable dork.

# configuration and environment files
site:example.com filetype:env intext:"DB_PASSWORD"
site:example.com inurl:wp-config.php
site:example.com filetype:ini intext:"[database]"

# backups and dumps left in the web root
site:example.com (filetype:bak OR filetype:old OR filetype:zip)
site:example.com filetype:sql intext:"INSERT INTO"

# directory listing turned on by accident
site:example.com intitle:"index of" (inurl:backup OR inurl:uploads)

A directory listing is the autoindex page Apache or Nginx serves when a folder has no index file. The giveaway is a title that starts with "index of" and a "Parent Directory" link, and from there you can read every file the folder holds. Confirm one is reachable with a simple request so you are sure the index is live and not a stale cache, and do this only inside your authorized scope.

$ curl -s -o /dev/null -w "%{http_code} %{content_type}\n" https://example.com/backup/
200 text/html
$ curl -sI https://example.com/backup/db.sql | head -n1
HTTP/1.1 200 OK

07Documents and the metadata they carry

Documents leak more than the text on the page, because office files and PDFs carry metadata that the author never sees. A single filetype: query against a domain pulls every indexed report, spreadsheet, and slide deck, and the file properties inside often list usernames, internal software versions, and local file paths that map out the network behind the site.

site:example.com filetype:pdf
site:example.com (filetype:xlsx OR filetype:docx OR filetype:pptx)
site:example.com filetype:pdf intext:"confidential"

Once you have a document from an authorized target, a metadata reader shows what is hiding in the file properties. exiftool is the standard choice and reads almost any format.

$ exiftool report.pdf
Author              : j.okoro
Creator             : Microsoft Word 2016
Producer            : Acrobat Distiller 11
Create Date         : 2023:04:18 09:22:14
Company             : Example Corp

Collected across dozens of documents, those fields give a username convention, a software inventory, and sometimes internal hostnames. Tools like FOCA and metagoofil automate the whole loop, searching for documents on a domain and extracting their metadata in bulk, which is a tidy demonstration of why metadata scrubbing belongs in every publishing workflow.

08The Google Hacking Database

The Google Hacking Database is a public catalog of proven dorks, so you rarely have to invent one from scratch. It began as Johnny Long's collection and is now maintained by Offensive Security on Exploit-DB, where each entry is a ready to run query filed under a category and tagged with what it finds. Browsing it is a fast way to learn the patterns and to check whether a class of exposure applies to your target.

The healthy way to use it is to read an entry, understand why the query works, then adapt it to your authorized scope by scoping it with site:. Copying a dork blindly against the open internet is how beginners drift out of scope and into trouble.

# take a GHDB pattern and pin it to one authorized domain
intitle:"index of" "backup"            the raw GHDB-style pattern
site:example.com intitle:"index of" "backup"   the same idea, kept in scope

09Limits, rate limits, and etiquette

The limits on dorking are mostly about how you query, not what you search for, because the index itself is public. Google watches for automated traffic: fire hundreds of queries from a script and you will meet a CAPTCHA or an HTTP 429, and heavy scraping breaks the terms of service. Manual searching in a browser is fine, and if you need volume, do it slowly or through a sanctioned search API rather than hammering the web UI.

Keep three rules straight and you stay on the right side of both the law and etiquette.

10A worked example against example.com

A worked example ties the operators together into the order you would actually run them on an authorized assessment. The target here is the generic example.com, standing in for a scoped domain. The flow goes from a wide map of the site down to the specific files worth a closer look, and every step is a single search in the browser.

# a full recon pass, scoped to one authorized domain
site:example.com
site:example.com -www -blog
site:example.com (inurl:login OR inurl:admin OR intitle:"sign in")
site:example.com (filetype:env OR filetype:sql OR filetype:bak OR filetype:log)
site:example.com intitle:"index of" "parent directory"
site:example.com filetype:pdf intext:"internal"

Each line trims the one before it. By the last query you are no longer browsing a website, you are reading a short list of specific exposures, and you can write each one into the report with the exact query that found it so the owner can reproduce it.

11Finding your own exposures before someone else does

Monitoring your own domain with the same dorks is the detection half of this topic, and it is the cheapest security win a site owner has. Run the panel, file, and directory queries against your own site: on a schedule, and anything new that appears is an exposure to investigate the same day. Google Search Console backs this up: its page indexing report lists exactly what Google has stored for you, so a file you never meant to publish shows up there before an attacker's dork ever finds it.

Set a reminder to re-run the worked example queries against your domains monthly, and treat any fresh hit on a config file, backup, or admin panel as an incident. The attacker's recon and the defender's audit are the identical search, which is what makes self-dorking such a good habit.

12Defending your site against dorking

Defending against dorking means removing the exposure, not hiding the link to it, because the single biggest mistake owners make is treating crawl directives as a lock. The fixes below are ordered the way you should apply them, from stopping the leak at the source to cleaning up what is already in the index.

# robots.txt discourages crawling but is public and advertises your paths
User-agent: *
Disallow: /admin/

13FAQ