1000 Best Google Dorks List (Google Hacking Guide) – 2026
A Google dork is an advanced search query that combines Google’s search operators (such as site:, intitle:, inurl:, and filetype:) to surface information that is publicly indexed but hard to find through normal searching. Security professionals use Google dorking (also called Google hacking) for OSINT, reconnaissance, and to discover—and fix—their own exposed files, login pages, and misconfigurations before attackers do.
⚠ Legal & ethical notice. Everything in this guide is provided for education, defensive security, authorized penetration testing, and security research. Running a search is legal; acting on what you find is not always. Only test domains you own or have explicit written permission to assess. Accessing systems, downloading private data, or using exposed credentials without authorization can violate the U.S. Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act 1990, the EU’s cybercrime statutes, India’s IT Act 2000, and similar laws worldwide. When in doubt, don’t. See the Is Google dorking legal? section below.
Google dorks are specially crafted search queries that use Google’s advanced search operators to filter results with surgical precision. Instead of typing a few keywords and scrolling through millions of pages, a dork tells Google exactly what to look for and where: a specific file type, a phrase in a page title, a string in a URL, or content on a single domain. The technique is also known as Google dorking, Google hacking, or Google-fu.
The term traces back to security researcher Johnny Long, who began cataloguing revealing search queries around 2002 and coined “googledork” for a query that exposes sensitive information. His work grew into the Google Hacking Database (GHDB), now maintained by Offensive Security as part of Exploit-DB, which today holds thousands of community-submitted dorks across more than a dozen categories.
Crucially, Google dorks do not “hack” anything in the traditional sense. They exploit no software vulnerability and break no authentication. They simply reveal what is already public in Google’s index—pages and files that owners exposed by accident and that Google’s crawler dutifully catalogued. That is exactly why the technique is so valuable to defenders: if a dork can find your exposed database backup, so can an attacker.
To understand dorking, it helps to understand indexing. Google’s crawler (Googlebot) follows links across the web, downloads pages, and stores a processed copy in its index along with metadata: the page title, the URL, the visible text, the file type, and the date it was crawled. Search operators are simply filters that query that metadata directly.
When you search filetype:pdf site:example.com “confidential”, you are asking Google to return only PDF files, only on example.com, that contain the word “confidential.” The power of dorking comes from stacking these filters. A single operator narrows results; three or four combined can isolate a specific exposed file among billions of pages.
Anything Googlebot can reach and is allowed to index can surface in a dork. That includes directory listings left open on misconfigured servers, backup files with predictable names, log files, configuration files, spreadsheets, and login portals—none of which the owner intended to publish, but all of which became public the moment they were placed in a crawlable location without protection.
Yes—with an important line. Performing a Google search, no matter how advanced the operators, is legal virtually everywhere; you are only querying a public index that Google built. The legal risk begins when you act on the results in an unauthorized way.
Viewing a page Google returns is generally fine. But using an exposed username and password to log in, downloading a database that was never meant to be public, probing a discovered admin panel, or exfiltrating personal data crosses from “searching” into “unauthorized access”—which is a crime under laws including the U.S. Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act 1990, the EU Directive on attacks against information systems, and India’s Information Technology Act 2000 (Sections 43 & 66). Bypassing a paywall or authentication page can also constitute a violation of Google’s Terms of Service and local IP law.
The safe rule for professionals: only dork assets you own or are contractually authorized to test, keep evidence of that authorization (scope documents, rules of engagement), and if you accidentally discover a third party’s exposed data, stop and report it responsibly rather than accessing it. This article is not legal advice; when a real engagement is involved, consult your legal team.
Every dork is built from operators. Below are the operators that currently work in Google Search as of 2026. Master these and you can construct any dork in this guide—and thousands more of your own.
Several classic operators that appear in older dork lists no longer work or have been officially retired by Google. If a dork you copy from an old tutorial returns nothing, one of these is often why.
The real skill of dorking is chaining operators. Start broad, then add filters until only the target remains. A reliable recon pattern is: pick a target scope with site:, choose a signal with intitle: or inurl:, then constrain the format with filetype: and the content with intext:.
A few worked examples that show the pattern:
Open directory of backups on one site: site:example.com intitle:”index of” (backup OR bak OR old)
Exposed environment file with an API key: filetype:env intext:”API_KEY” -site:github.com
Login portals on a domain: site:example.com (inurl:login OR inurl:admin OR intitle:”sign in”)
Spreadsheets that mention passwords: filetype:xls intext:password intext:username
Notice the use of OR groups in parentheses, negative filters like -site:github.com to cut noise, and stacked intext: terms to require multiple signals. These same building blocks power every category below.
Below are 1000 practical Google dorks organized into 25 categories—from open directory listings and exposed credentials to cloud buckets, IoT devices, CMS platforms, and OSINT people-search queries. Each category opens with a one-line explanation of what it surfaces and why it matters, followed by ready-to-use dorks.
How to use this list responsibly: append site:yourdomain.com to any dork to audit your own attack surface. That single addition turns an offensive query into a defensive one, showing you exactly what Google has indexed about your organization. Do not run these against assets you don’t own or aren’t authorized to test.
1. Open Directory Listings (“Index of”)
Misconfigured servers with directory browsing enabled expose entire folder trees. These are the classic starting point for dorking and often the fastest way to find backups, configs, and credentials left in the open.
intitle:”index of” “admin”
intitle:”index of” “backup”
intitle:”index of” “backups”
intitle:”index of” “bak”
intitle:”index of” “old”
intitle:”index of” “private”
intitle:”index of” “secret”
intitle:”index of” “secrets”
intitle:”index of” “config”
intitle:”index of” “configs”
intitle:”index of” “database”
intitle:”index of” “db”
intitle:”index of” “sql”
intitle:”index of” “dump”
intitle:”index of” “dumps”
intitle:”index of” “logs”
intitle:”index of” “log”
intitle:”index of” “ftp”
intitle:”index of” “uploads”
intitle:”index of” “upload”
intitle:”index of” “files”
intitle:”index of” “docs”
intitle:”index of” “documents”
intitle:”index of” “data”
intitle:”index of” “temp”
intitle:”index of” “tmp”
intitle:”index of” “cache”
intitle:”index of” “credentials”
intitle:”index of” “passwords”
intitle:”index of” “password”
intitle:”index of” “keys”
intitle:”index of” “ssh”
intitle:”index of” “ssl”
intitle:”index of” “certs”
intitle:”index of” “mail”
intitle:”index of” “email”
intitle:”index of” “invoices”
intitle:”index of” “finance”
intitle:”index of” “hr”
intitle:”index of” “employees”
intitle:”index of” “users”
intitle:”index of” “members”
intitle:”index of” “students”
intitle:”index of” “downloads”
intitle:”index of” “media”
intitle:”index of” “images”
intitle:”index of” “videos”
intitle:”index of” “includes”
intitle:”index of” “vendor”
intitle:”index of” “node_modules”
intitle:”index of” “cgi-bin”
intitle:”index of” “wp-content”
intitle:”index of” “wp-admin”
intitle:”index of” “.git”
intitle:”index of” “.env”
intitle:”index of” “.svn”
intitle:”index of” “error_log”
intitle:”index of” “backup.zip”
intitle:”index of” “backup.sql”
intitle:”index of” “database.sql”
intitle:”index of” “www.zip”
intitle:”index of” “site.zip”
intitle:”index of” “dump.sql”
intitle:”index of” “passwords.txt”
intitle:”index of /” backup
intitle:”index of /” “parent directory”
intitle:”index of /admin”
intitle:”index of /backup”
intitle:”index of /private”
intitle:”index of /wp-content”
intitle:”index of” “server at”
2. Files Containing Passwords & Credentials
Site owners sometimes leave spreadsheets, logs, and config files containing usernames and passwords in crawlable locations. Defenders should run these against their own domain first — an exposed credential file is a five-alarm fire.
Configuration and .env files routinely hold database credentials, secret keys, and API tokens. Keep them out of the web root and never commit them to indexed locations.
filetype:ini intext:”password”
filetype:conf intext:”password”
filetype:cfg intext:”password”
filetype:config intext:”password”
filetype:cnf intext:”password”
filetype:yaml intext:”password”
filetype:yml intext:”password”
filetype:properties intext:”password”
filetype:toml intext:”password”
filetype:json intext:”password”
filetype:env intext:”password”
filetype:env “DB_PASSWORD”
filetype:env “APP_KEY”
filetype:env “API_KEY”
filetype:env “SECRET”
ext:env intext:”DB_HOST”
inurl:”.env” intext:”APP_ENV”
inurl:wp-config.php
inurl:config.php intext:”DB_PASSWORD”
inurl:configuration.php
inurl:web.config filetype:config
inurl:settings.py “SECRET_KEY”
inurl:application.properties
inurl:appsettings.json
inurl:config.yml
inurl:config.yaml
inurl:config.json
inurl:database.yml
inurl:secrets.yml
inurl:”/config/database.php”
inurl:”local.xml” magento
inurl:”web.config”
intitle:”index of” “config.php”
intitle:”index of” “wp-config.php”
intitle:”index of” “settings.py”
filetype:cnf my.cnf intext:password
filetype:properties intext:”jdbc”
filetype:yml “password:”
filetype:yaml “secret:”
filetype:conf inurl:httpd.conf
filetype:conf inurl:nginx.conf
filetype:ini “[database]”
inurl:”.env.local”
inurl:”.env.production”
inurl:”config.inc.php”
inurl:”connectionstrings” filetype:config
inurl:”standalone.xml” jboss
filetype:xml “connectionString”
inurl:”phpunit.xml”
ext:cfg intext:password
4. Database Files & SQL Dumps
Exposed .sql dumps and database files can leak entire tables, including hashed or plaintext passwords. Store backups off-web and behind authentication.
filetype:sql intext:”INSERT INTO”
ext:sql intext:”INSERT INTO”
ext:sql intext:”CREATE TABLE”
ext:sql intext:”DROP TABLE”
ext:sql “– phpMyAdmin SQL Dump”
ext:sql “password”
ext:sql “VALUES” “@gmail.com”
filetype:sql “MySQL dump”
filetype:sql “– Server version”
filetype:sql inurl:backup
filetype:sql “INSERT INTO users”
filetype:sql “INSERT INTO `users`”
filetype:sql “CREATE DATABASE”
filetype:sql “IDENTIFIED BY”
filetype:sql intitle:”index of”
filetype:db intitle:”index of”
filetype:mdb intitle:”index of”
filetype:sqlite intitle:”index of”
filetype:sqlite3 intitle:”index of”
filetype:dbf intitle:”index of”
filetype:bak intitle:”index of”
filetype:sql.gz intitle:”index of”
filetype:sql.zip intitle:”index of”
intitle:”index of” “db.sql”
intitle:”index of” “*.sql”
inurl:dump.sql
inurl:database.sql
inurl:backup.sql
intitle:”phpMyAdmin” “Welcome to phpMyAdmin”
intitle:”phpMyAdmin” “running on”
inurl:phpmyadmin/index.php
intext:”phpMyAdmin SQL Dump” filetype:sql
filetype:mdb inurl:fpdb
filetype:mdb administrators
ext:sqlite intitle:”index of”
filetype:db intext:”password”
inurl:”/backups/” filetype:sql
intitle:”index of” “adminer.php”
inurl:adminer.php
filetype:sql “current database”
filetype:sql “phpmyadmin”
intext:”– Dumping structure for table”
5. Log Files
Log files can reveal usernames, session tokens, internal paths, SQL statements, and stack traces. Suppress verbose logging in production and never serve log directories.
filetype:log intext:”password”
filetype:log intext:”error”
filetype:log intext:”access”
filetype:log intext:”debug”
filetype:log intext:”username”
filetype:log intext:”login”
filetype:log intext:”failed login”
filetype:log intext:”sql”
filetype:log intext:”php”
filetype:log intext:”ssh”
filetype:log intext:”ftp”
filetype:log intext:”mysql”
filetype:log intext:”exception”
filetype:log intext:”stack trace”
filetype:log intext:”warning”
filetype:log intext:”api_key”
filetype:log intext:”token”
filetype:log intext:”session”
inurl:error_log
inurl:access_log
inurl:debug.log
inurl:”/logs/”
intitle:”index of” “*.log”
intitle:”index of” “error.log”
intitle:”index of” “access.log”
filetype:log “PHP Parse error”
filetype:log “PHP Warning”
filetype:log “PHP Fatal error”
filetype:log inurl:”access.log”
filetype:log “HTTP_USER_AGENT”
allintext:”error” filetype:log
filetype:log “password” “login”
inurl:wp-content/debug.log
filetype:log “GET /” “200”
filetype:log “authentication failure”
filetype:log “sshd”
filetype:log “Failed password for”
6. Backup & Old Files
Predictably named backups (backup.zip, wp-config.php.bak, site.tar.gz) are a favorite target. Rename, remove, or protect them and disable directory listing.
ext:bak inurl:backup
ext:old inurl:backup
ext:backup inurl:backup
ext:bkp inurl:backup
inurl:”.bak”
inurl:”.old”
inurl:”.backup”
inurl:”.save”
inurl:”.orig”
intitle:”index of” “*.bak”
intitle:”index of” “*.old”
intitle:”index of” “backup.tar.gz”
intitle:”index of” “web.zip”
filetype:zip inurl:backup
filetype:tar inurl:backup
filetype:gz inurl:backup
filetype:rar inurl:backup
filetype:7z inurl:backup
filetype:tgz backup
inurl:backup filetype:zip
inurl:”backup” intext:”index of”
ext:bak “index of”
inurl:wp-config.php.bak
inurl:config.php.bak
inurl:index.php.bak
inurl:”.sql.bak”
inurl:”.env.bak”
inurl:”.env.save”
inurl:”/backup/” filetype:zip
inurl:”/old/” intitle:”index of”
filetype:zip “backup” site:
ext:old inurl:php
inurl:database.bak
inurl:”backup.tar”
inurl:”backup.tar.gz”
inurl:”dump.tar.gz”
intitle:”index of” “old files”
7. Login & Admin Portals
Admin panels, CMS logins, webmail, and control panels are gold to attackers. Put them behind MFA, IP allow-listing, or a VPN, and consider hiding them from indexing.
intitle:”login”
intitle:”admin login”
intitle:”administrator login”
intitle:”sign in”
intitle:”control panel”
intitle:”dashboard”
intitle:”admin panel”
intitle:”please login”
intitle:”user login”
intitle:”member login”
intitle:”portal login”
intitle:”webmail login”
inurl:admin
inurl:login
inurl:signin
inurl:auth
inurl:administrator
inurl:adminpanel
inurl:admin_area
inurl:cpanel
inurl:wp-login.php
inurl:wp-admin
inurl:user/login
inurl:account/login
inurl:admin/login
inurl:adminlogin
inurl:login.php
inurl:admin.php
inurl:admin/index.php
inurl:panel
inurl:backend
inurl:manage
inurl:administrator/index.php
inurl:secure/login
inurl:admin/dashboard
“admin” inurl:login
intitle:”cPanel” inurl:cpanel
intitle:”Webmin” inurl:10000
intitle:”Plesk” login
intitle:”phpMyAdmin”
inurl:”/manager/html” intitle:”Apache Tomcat”
intitle:”Grafana” inurl:login
intitle:”Kibana” inurl:app
intitle:”Jenkins” inurl:login
inurl:/wp-admin/
intitle:”Login” inurl:”/admin”
intitle:”Sign In” inurl:”/account”
inurl:”/administrator/” intitle:”login”
intitle:”Router” inurl:login
intitle:”Outlook Web App”
intitle:”Zimbra” inurl:zimbra
intitle:”RoundCube Webmail”
intitle:”Horde” login
intitle:”OpenVPN” login
intitle:”pfSense” login
intext:”Login” “Forgot Password” inurl:admin
intitle:”Administration Login”
8. Sensitive Documents (PDF, DOC, XLS)
Confidential PDFs, spreadsheets, and slide decks are frequently indexed by accident. Mark internal documents noindex, store them behind authentication, and audit what Google has cached about your brand.
filetype:pdf intext:confidential
filetype:pdf intext:”not for distribution”
filetype:pdf intext:”internal use only”
filetype:pdf intext:proprietary
filetype:pdf intext:”for internal use”
filetype:pdf intext:salary
filetype:pdf intext:budget
filetype:pdf intext:invoice
filetype:pdf intext:”social security”
filetype:pdf intext:passport
filetype:pdf intext:resume
filetype:pdf intext:cv
filetype:pdf intext:contract
filetype:pdf intext:nda
filetype:pdf intext:”strictly confidential”
filetype:pdf intext:”company confidential”
filetype:doc intext:confidential
filetype:doc intext:”internal use only”
filetype:docx intext:confidential
filetype:docx intext:”internal use only”
filetype:xls intext:confidential
filetype:xls intext:”internal use only”
filetype:xlsx intext:confidential
filetype:xlsx intext:”internal use only”
filetype:csv intext:confidential
filetype:csv intext:”internal use only”
filetype:txt intext:confidential
filetype:txt intext:”internal use only”
filetype:pdf “confidential” “do not distribute”
filetype:xls “salary”
filetype:xlsx “budget” “confidential”
filetype:pdf “employee” “ssn”
filetype:docx “non-disclosure agreement”
filetype:pdf “bank statement”
filetype:xls “invoice” “total due”
filetype:pdf intext:”proprietary and confidential”
filetype:doc “meeting minutes” confidential
filetype:pptx “internal” “roadmap”
filetype:pdf “tax return”
filetype:csv “first name” “last name” “email”
filetype:xlsx “employee list”
filetype:pdf “patient” “confidential”
filetype:pdf inurl:confidential
filetype:doc “for internal distribution only”
9. Exposed Cameras & Webcams
Thousands of IP cameras ship with default web interfaces that end up indexed. This is a textbook example of IoT exposure — change defaults, require authentication, and keep camera portals off the public internet.
inurl:”/view.shtml”
inurl:”ViewerFrame?Mode=”
inurl:”axis-cgi/mjpg”
inurl:”/mjpg/video.mjpg”
inurl:”control/userimage.html”
inurl:”/view/index.shtml”
inurl:”/webcam.html”
inurl:”/axis-cgi/jpg/image.cgi”
inurl:”/cgi-bin/guestimage.html”
inurl:”/ViewerFrame?Mode=Motion”
inurl:”snapshot.cgi”
inurl:”video.cgi”
inurl:”/live/index.html” camera
inurl:”/webcapture.jpg”
inurl:”/img/main.cgi”
intitle:”webcamXP 5″
intitle:”Live View / – AXIS”
intitle:”network camera”
intitle:”IP Camera” inurl:login
intitle:”toshiba network camera”
intitle:”Live NetSnap Cam-Server feed”
intitle:”i-Catcher Console”
intitle:”WEBCAM 7″ inurl:8080
intitle:”Camera” inurl:”/view/viewer_index.shtml”
intitle:”Axis Video Server”
intitle:”D-Link” “Live View”
intitle:”EvoCam”
intitle:”snc-rz30 home”
intitle:”WJ-NT104 Main Page”
intitle:”Live View” “AXIS 206”
intitle:”Hikvision” inurl:doc
intitle:”IVC video server”
intitle:”MOBOTIX”
inurl:”/anony/mjpg.cgi”
inurl:”:8080″ intitle:”webcam”
inurl:”indexFrame.shtml” Axis
intitle:”supervisioncam protocol”
inurl:”/CgiStart?page=Single”
intitle:”active webcam page”
intitle:”Panasonic Network Camera”
10. Network Devices (Routers, Printers, Switches)
Router, switch, and printer web interfaces exposed to the internet are common. Restrict management interfaces to internal networks and change every default credential.
Verbose errors and phpinfo() pages leak file paths, software versions, database structure, and sometimes credentials — a reconnaissance goldmine and a sign of SQL-injection points. Disable debug output in production.
intext:”Warning: mysql_connect()”
intext:”Warning: mysql_query()”
intext:”Warning: pg_connect()”
intext:”Fatal error: Uncaught”
intext:”You have an error in your SQL syntax”
intext:”supplied argument is not a valid MySQL”
intext:”ORA-00933: SQL command not properly ended”
intext:”Microsoft OLE DB Provider for ODBC Drivers error”
intext:”Unclosed quotation mark after the character string”
intext:”[an error occurred while processing this directive]”
intext:”Call to undefined function”
intext:”mysql_fetch_array()”
intext:”SQLSTATE[” “SQL:”
intext:”DEBUG = True” django
intext:”Warning: file_get_contents”
intext:”Uncaught PDOException”
intext:”Fatal error” “on line” inurl:php
intext:”Parse error: syntax error”
12. Web Server & Technology Detection
Default landing pages, status endpoints, and “Powered by” footers fingerprint the server and framework, helping attackers match known CVEs. Remove default pages and strip version banners.
intitle:”Apache2 Ubuntu Default Page”
intitle:”Apache2 Debian Default Page”
intitle:”Apache HTTP Server Test Page”
intitle:”Test Page for the Apache”
intitle:”Welcome to nginx!”
intitle:”IIS Windows Server”
intitle:”IIS7″
intitle:”Test Page for the SSL/TLS-aware Apache”
intitle:”Welcome to CentOS”
inurl:server-status “Apache Server Status”
inurl:server-info “Apache Server Information”
intitle:”index of” “Server at”
intitle:”Welcome to XAMPP”
intitle:”Welcome to WAMP”
intitle:”Dashboard [Jenkins]”
intitle:”Welcome to your new home in the cloud”
intitle:”Directory Listing For” “Tomcat”
intitle:”Apache Tomcat” “Server Information”
intitle:”phpinfo()” “System”
intitle:”Welcome to Windows Server”
intext:”Powered by WordPress” inurl:wp-content
intext:”Powered by Joomla”
intext:”Powered by Drupal”
intext:”Powered by Magento”
intext:”Powered by Shopify”
intitle:”Welcome to lighttpd”
intitle:”Default Web Site Page”
intitle:”HTTP Server Test Page powered by CentOS”
intitle:”It works!” apache
intext:”Server: Apache” intitle:”index of”
intitle:”Setup Configuration” xampp
inurl:”/web-console” jboss
intitle:”JBoss” management
intitle:”GlassFish Server”
intitle:”WildFly” management
13. Cloud Storage Exposure (S3, Azure, GCS)
Public cloud buckets and blobs leak files at scale. Block public access by default, audit ACLs regularly, and search these hosts for your own organization’s name.
site:s3.amazonaws.com
site:blob.core.windows.net
site:storage.googleapis.com
site:digitaloceanspaces.com
site:s3.us-east-1.amazonaws.com
site:s3-eu-west-1.amazonaws.com
site:s3.ap-south-1.amazonaws.com
site:s3.amazonaws.com “backup”
site:s3.amazonaws.com “confidential”
site:s3.amazonaws.com “private”
site:s3.amazonaws.com “password”
site:s3.amazonaws.com “.sql”
site:s3.amazonaws.com “.env”
site:s3.amazonaws.com “dump”
site:s3.amazonaws.com “invoice”
site:s3.amazonaws.com “employees”
site:s3.amazonaws.com filetype:sql
site:s3.amazonaws.com filetype:xls
site:s3.amazonaws.com filetype:pdf confidential
site:s3.amazonaws.com “index of”
site:blob.core.windows.net filetype:pdf
site:blob.core.windows.net “confidential”
site:storage.googleapis.com “backup”
site:storage.googleapis.com filetype:sql
inurl:s3.amazonaws.com filetype:xlsx
site:amazonaws.com “aws_access_key_id”
inurl:”.s3.amazonaws.com” “index of”
site:firebaseio.com
inurl:firebaseio.com “.json”
site:digitaloceanspaces.com “backup”
site:s3.amazonaws.com “database”
site:appspot.com “error”
site:herokuapp.com inurl:admin
site:blob.core.windows.net filetype:xlsx
site:s3.amazonaws.com “passwords”
14. API Keys & Secrets
Leaked API keys and private keys let attackers impersonate your services and rack up cloud bills. Use a secrets manager, scan repos and pages for tokens, and rotate anything that may be exposed.
intext:”api_key” filetype:env
intext:”api_key” filetype:json
intext:”api_key” filetype:txt
intext:”api_key” filetype:log
intext:”api_key” filetype:yml
intext:”api_key” filetype:yaml
intext:”api_key” filetype:xml
intext:”api_key” filetype:config
intext:”api_key” filetype:ini
intext:”apikey” filetype:json
intext:”api key” filetype:txt
intext:”AKIA” filetype:env
intext:”aws_access_key_id” filetype:env
intext:”aws_secret_access_key”
intext:”client_secret” filetype:json
intext:”client_id” “client_secret”
intext:”private_key” filetype:json
intext:”—–BEGIN RSA PRIVATE KEY—–“
intext:”—–BEGIN OPENSSH PRIVATE KEY—–“
intext:”—–BEGIN PRIVATE KEY—–” filetype:key
intext:”—–BEGIN DSA PRIVATE KEY—–“
intext:”authorization: Bearer” filetype:log
intext:”xoxb-” slack token
intext:”xoxp-” filetype:txt
intext:”sk_live_” stripe
intext:”sk_test_” filetype:txt
intext:”ghp_” github token
intext:”AIza” google api key
intext:”SG.” sendgrid
intext:”twilio” “auth_token”
filetype:json “google_api_key”
inurl:”/.env” “APP_KEY”
filetype:env “MAIL_PASSWORD”
filetype:env “STRIPE_SECRET”
filetype:yml “secret_key_base”
intext:”BEGIN CERTIFICATE” filetype:pem
filetype:pem intext:”PRIVATE KEY”
intext:”heroku” “api_key”
filetype:json intext:”refresh_token”
intext:”db_password” filetype:yml
filetype:properties “aws.secret”
intext:”firebase” “apiKey” filetype:json
intext:”jwt” “secret” filetype:env
intext:”consumer_secret” filetype:txt
filetype:json “type”: “service_account”
15. Git & Version Control Exposure
An exposed /.git/ folder lets an attacker reconstruct your entire source tree — including secrets in commit history. Block access to VCS metadata directories at the web-server level.
inurl:”.git” intitle:”index of”
inurl:”/.git/config”
inurl:”/.git/HEAD”
inurl:”/.git/logs/HEAD”
inurl:”/.git/index”
inurl:”.gitignore” intitle:”index of”
inurl:”/.gitconfig”
inurl:”.svn/entries”
inurl:”.svn/wc.db”
inurl:”.hg” intitle:”index of”
inurl:”.bzr” intitle:”index of”
inurl:”.git/refs/heads”
intext:”[core]” inurl:.git/config
inurl:”/.git” “index of” “config”
inurl:”.git/description”
inurl:”/.git/packed-refs”
filetype:git-credentials
inurl:”.git-credentials”
inurl:”/.gitlab-ci.yml”
inurl:”/CVS/Root”
inurl:”/CVS/Entries”
inurl:”.git” “COMMIT_EDITMSG”
inurl:”/.github/workflows”
inurl:”.dockerignore” “index of”
inurl:”composer.lock” intitle:”index of”
inurl:”package-lock.json” intitle:”index of”
inurl:”.git/ORIG_HEAD”
inurl:”.git/FETCH_HEAD”
inurl:”/.git/info/refs”
inurl:”/.git/logs/refs/heads/master”
inurl:”.gitattributes” intitle:”index of”
inurl:”/.terraform” intitle:”index of”
inurl:”terraform.tfstate”
inurl:”/.git/refs/tags”
16. Payment & Financial Data
Spreadsheets with card numbers, bank details, invoices, and payroll are catastrophic if indexed. This is PCI/regulatory territory — encrypt, restrict, and never expose financial files to crawlers.
filetype:xls intext:”credit card”
filetype:xls intext:”card number”
filetype:xls intext:cvv
filetype:xls intext:”expiration date”
filetype:xls intext:”bank account”
filetype:xls intext:iban
filetype:xls intext:swift
filetype:xls intext:”routing number”
filetype:xls intext:”account number”
filetype:xlsx intext:”credit card”
filetype:xlsx intext:”card number”
filetype:xlsx intext:cvv
filetype:xlsx intext:”expiration date”
filetype:xlsx intext:”bank account”
filetype:xlsx intext:iban
filetype:xlsx intext:swift
filetype:xlsx intext:”routing number”
filetype:xlsx intext:”account number”
filetype:csv intext:”credit card”
filetype:csv intext:”card number”
filetype:csv intext:cvv
filetype:csv intext:”expiration date”
filetype:csv intext:”bank account”
filetype:csv intext:iban
filetype:csv intext:swift
filetype:csv intext:”routing number”
filetype:csv intext:”account number”
filetype:xls “invoice” “amount due”
filetype:xlsx “transactions” “balance”
filetype:csv “card number” “expiry”
filetype:pdf “invoice” “payment terms”
intitle:”index of” “payments”
filetype:xls “salary” “bonus”
filetype:pdf “bank statement” “account balance”
filetype:csv “iban” “swift”
filetype:xlsx “payroll”
filetype:pdf “purchase order”
filetype:xls “budget” “actual” “forecast”
intext:”cardholder” filetype:xls
filetype:csv “ccnum” OR “card_number”
filetype:xls “invoice number” “vat”
17. Email Lists & Personal Data (PII)
Contact lists, customer databases, and HR spreadsheets full of PII fuel phishing and identity theft. Treat these as regulated data (GDPR/CCPA) and keep them entirely off the indexable web.
Content management systems have well-known file paths that expose configs, backups, user lists, and version info. Keep CMS core files patched and block sensitive paths.
inurl:wp-content/uploads
inurl:”/wp-json/wp/v2/users”
intitle:”index of” “wp-content/plugins”
inurl:xmlrpc.php
inurl:”/wp-login.php”
inurl:wp-content/uploads filetype:sql
inurl:”wp-content/uploads” “backup”
inurl:”/wp-content/uploads/dump.sql”
inurl:”readme.html” wordpress
inurl:”/wp-content/uploads/” filetype:xls
inurl:”wp-content/uploads/2024″
inurl:”/wp-content/uploads/wpallimport”
inurl:”wp-content/ai1wm-backups”
inurl:”option=com_” joomla
inurl:administrator/index.php joomla
intext:”Joomla! – Open Source Content Management”
inurl:”configuration.php-dist”
inurl:”/administrator/manifests/files/joomla.xml”
inurl:”com_users” joomla
inurl:”/language/en-GB/en-GB.xml” joomla
inurl:”/user/register” drupal
intitle:”Welcome to your new Drupal”
inurl:”CHANGELOG.txt” drupal
inurl:”/sites/default/files”
inurl:”/sites/default/settings.php”
inurl:”/core/CHANGELOG.txt” drupal
inurl:”/user/login” drupal
inurl:”/downloader” magento
inurl:”app/etc/local.xml” magento
intitle:”Magento Admin” inurl:admin
inurl:”/magento_version”
inurl:”/rss/catalog/notifystock” magento
inurl:”/skin/frontend” magento
inurl:”/typo3/” login
intext:”Powered by TYPO3″
inurl:”/administrator/logs” joomla
inurl:”/wp-content/uploads/” “index of”
inurl:”/bitrix/admin”
intitle:”Dashboard” inurl:”/ghost/”
inurl:”/umbraco/” login
19. Vulnerable Parameters (SQLi / LFI Candidates)
URL parameters that reflect into queries or file paths are candidate injection points. Test these only on assets you own or are authorized to assess; use them to find and fix input-validation gaps.
inurl:”id=”
inurl:”page=”
inurl:”cat=”
inurl:”category=”
inurl:”product=”
inurl:”pid=”
inurl:”item=”
inurl:”file=”
inurl:”path=”
inurl:”dir=”
inurl:”view=”
inurl:”include=”
inurl:”page_id=”
inurl:”p=”
inurl:”news_id=”
inurl:”article=”
inurl:”story=”
inurl:”user_id=”
inurl:”order=”
inurl:”sort=”
inurl:”query=”
inurl:”q=”
inurl:”index.php?id=” intext:”You have an error in your SQL syntax”
inurl:”page.php?id=” “mysql_fetch”
inurl:”?cat=” “Warning: mysql”
inurl:”?file=” “include(“
inurl:”?page=” “root:x:0:0”
inurl:”?path=” “index of”
inurl:”?include=” “.php”
inurl:”product.php?id=” “SQL syntax”
inurl:”category.php?id=”
inurl:”news.php?id=”
inurl:”gallery.php?id=”
inurl:”view.php?id=”
inurl:”article.php?id=”
inurl:”download.php?file=”
inurl:”index.php?page=”
inurl:”?redirect=” http
inurl:”?url=” http
inurl:”?return=” http
inurl:”?next=” http
inurl:”?dest=” http
20. FTP Servers & Exposed File Shares
Open FTP directories and leftover FTP client config files (WS_FTP, FileZilla) can expose stored server credentials. Disable anonymous FTP and never leave client config files web-accessible.
intitle:”index of” inurl:ftp
intitle:”index of” “ftp://”
intitle:”FTP root at”
inurl:ftp intext:”index of”
intitle:”index of” inurl:ftp “backup”
intitle:”index of” inurl:ftp filetype:sql
intitle:”index of” inurl:ftp “password”
inurl:”ftp://” “@” intext:”index of”
intitle:”index of” “pub” inurl:ftp
inurl:ftp “index of” “.txt”
inurl:ftp “index of” “config”
inurl:ftp “index of” “upload”
intitle:”index of” “incoming” ftp
inurl:”ftp.example” -site:example.com
intitle:”index of /pub” ftp
inurl:ftp filetype:log
inurl:ftp “index of” “private”
intitle:”index of” inurl:ftp “documents”
inurl:”vsftpd” “index of”
intitle:”index of” “ws_ftp.log”
filetype:log “ws_ftp”
inurl:”ws_ftp.ini”
intext:”ftp password” filetype:txt
inurl:”filezilla.xml”
inurl:”recentservers.xml” filezilla
filetype:ini “ws_ftp” pwd
intitle:”index of” “sitemanager.xml”
inurl:ftp “backup.zip”
inurl:ftp “database”
intitle:”index of” “ftp” “logs”
inurl:ftp “index of” “invoices”
intitle:”index of” “ftp” “credentials”
inurl:ftp filetype:csv “email”
21. IoT, SCADA & Industrial Devices
Industrial control systems and IoT gateways should never be internet-facing. Many still are. For deeper device discovery, pair these with Shodan and Censys; segment OT networks and require VPN access.
intitle:”Modbus” inurl:config
intitle:”SCADA” login
inurl:”/Portal/Portal.mwsl”
intitle:”Simatic” “S7”
intitle:”NetBotz Appliance”
intitle:”BAS” “building automation”
intitle:”Niagara Web Server”
intitle:”Tridium” login
intitle:”PLC” inurl:login
intitle:”HMI” inurl:login
intitle:”ioLogik” moxa
intitle:”Moxa” device
intitle:”BACnet” device
intitle:”EnergyICT”
intitle:”PRTG Network Monitor”
intitle:”Nagios” inurl:cgi-bin
intitle:”Zabbix” inurl:index.php
intitle:”Cacti” inurl:graph_view.php
intitle:”OpenHAB”
intitle:”Home Assistant”
intitle:”Loxone” miniserver
intitle:”Crestron” control
intitle:”AMX” NetLinx
intitle:”Domoticz”
intitle:”Sonoff” device
intitle:”Shelly” device login
intitle:”Solar” inverter monitoring
intitle:”Fronius” inverter
intitle:”SMA” “Sunny WebBox”
intitle:”Weintek” HMI
intitle:”Milesight” router
intitle:”Teltonika” router login
intitle:”Advantech” WebAccess
22. Government & Education Recon (TLD-Scoped)
Scoping dorks to a TLD or sector (site:gov, site:edu) surfaces sector-specific exposures. Use these to audit your own institution’s footprint.
site:gov filetype:pdf “confidential”
site:gov intitle:”index of”
site:gov filetype:xls
site:edu filetype:xls “student”
site:edu intitle:”index of” “grades”
site:edu filetype:pdf “confidential”
site:edu inurl:admin login
site:gov inurl:login
site:gov filetype:xlsx “budget”
site:ac.uk filetype:xls
site:gov.uk filetype:pdf “restricted”
site:edu “index of” “backup”
site:gov “index of” “database”
site:edu filetype:sql
site:gov inurl:”/wp-content”
site:k12 filetype:xls “students”
site:edu intext:”password” filetype:xls
site:gov intext:”internal use only” filetype:pdf
site:edu inurl:phpmyadmin
site:gov filetype:doc “for official use only”
site:edu “index of” “transcripts”
site:nic.in filetype:pdf
site:gov.in intitle:”index of”
site:edu.au filetype:xls
site:gov filetype:csv “employees”
site:gov filetype:sql
site:edu “index of” “database”
site:edu filetype:pdf “internal only”
site:gov.in filetype:xls “employees”
23. Social Media & People OSINT
Social platforms and paste/code-sharing sites expose profiles, contact details, and even leaked secrets. Investigators use these for OSINT; security teams use them to find their org’s data where it shouldn’t be.
Monitoring, CI/CD, and database admin dashboards left open give attackers deep visibility and often write access. Put every internal tool behind SSO/VPN and never expose them to the public internet.
VPN portals, remote-desktop gateways, and leftover connection files (.ovpn, .rdp) are prime targets for initial access. Enforce MFA on all remote access and keep connection profiles private.
Google dorking is a dual-use skill. The same query that helps an attacker find a weakness helps a defender close it first. Here is how different professionals put it to work.
Penetration testers & red teams
Dorking is a staple of the reconnaissance phase. Before touching a target (within an authorized scope), testers map the external attack surface: exposed subdomains, forgotten dev and staging servers, login portals, document leaks, and technology fingerprints. It is passive—queries hit Google, not the client—so it generates no traffic on the target and leaves no footprint.
Bug bounty hunters
On public bug-bounty programs, dorking quickly surfaces low-hanging fruit within scope: exposed .env files, API keys committed to indexed pages, open S3 buckets, and misconfigured dashboards. A well-built dork can find in seconds what manual browsing would miss for hours—always constrained to the program’s authorized scope.
OSINT analysts & investigators
For open-source intelligence, dorks find people, profiles, documents, and relationships across the indexed web—public records, leaked documents, social profiles, and organizational footprints. Investigators, journalists, and fraud teams rely on the same operators to corroborate facts from primary sources.
Blue teams & defenders
This is the most important use for most readers. By running the dorks in this guide with site:yourdomain.com appended, security teams perform continuous exposure monitoring—discovering what Google has indexed about them before an adversary does. Many organizations schedule weekly “self-dorking” scans and alert on new hits.
Journalists & academic researchers
Reporters and researchers use dorks to locate primary documents—government PDFs, budget spreadsheets, court filings, and datasets—that are technically public but effectively buried. It is a research accelerator, not an intrusion tool.
You can dork manually from any browser, but several tools make it faster and more systematic. Use automation carefully: sending too many automated queries triggers Google’s CAPTCHAs and temporary IP blocks, and mass-automating queries may conflict with Google’s Terms of Service.
Google Hacking Database (GHDB) – the canonical, community-maintained catalog at Exploit-DB, searchable by category and continuously updated with new dorks.
DorkSearch & similar dork builders – web tools that help you construct and preview dorks interactively without memorizing syntax.
Pagodo (passive Google dork) – an open-source Python tool that automates GHDB-based dorking while trying to evade rate limits; for authorized use only.
GooFuzz – a lightweight script that uses dorking techniques to enumerate directories, files, and users without directly hitting the target.
Recon frameworks – broader OSINT suites (such as theHarvester, Recon-ng, and SpiderFoot) incorporate search-engine dorking alongside other passive-recon modules.
For most defenders, no tooling is needed at all—a browser, this list, and a site: filter for your domain is enough to start finding and fixing exposures today.
Google dorking only works because sensitive content was crawlable in the first place. Close that gap and the dorks come up empty. Here is a defense-in-depth checklist.
Keep secrets out of the web root. Store configuration files, backups, database dumps, and .env files outside the publicly served directory. If it doesn’t need to be on the web, it shouldn’t be.
Disable directory listing. Turn off auto-indexing (Options -Indexes in Apache; ensure no autoindex in Nginx) so “index of” pages never render.
Use robots.txt—but understand its limit. robots.txt asks well-behaved crawlers not to index paths, but it is public and does not secure anything. Never list secret paths in it; treat it as a hint, not a lock.
Apply noindex properly. Use <meta name=”robots” content=”noindex”> or the X-Robots-Tag: noindex HTTP header on pages that must not appear in search.
Require authentication and MFA. Put admin panels, dashboards, and internal apps behind strong authentication with multi-factor and, ideally, IP allow-listing or a VPN.
Manage secrets correctly. Never hard-code API keys or passwords in files that could be served or committed to a public repo. Use a secrets manager and rotate any key that may have been exposed.
Lock down cloud storage. Audit S3, Azure Blob, and GCS bucket permissions; block public access by default and review ACLs regularly.
Suppress verbose errors. Disable debug output and detailed stack traces in production so error pages don’t leak paths, versions, or queries.
Remove what’s already indexed. Use Google Search Console’s Removals tool for urgent takedowns, then fix the root cause (add auth or noindex) so it doesn’t reappear.
Deploy a WAF and monitor. A web application firewall plus continuous self-dorking (weekly site: scans of your own domain) closes the loop—find exposures early and remediate fast.
Cyber Writes
Work done by a Team Of Security Experts from Cyber Writes (www.cyberwrites.com) - World’s First Dedicated Content-as-a-Service (CaaS) Platform for Cybersecurity. For Exclusive Cyber Security Contents, Reach at: business@cyberwrites.com
Good post. I learn something toitally new and challenging on sites
I stumbleupon onn a daily basis. It will always
be helpful to read through articles from other writers and
practice somethong from other sites.
View Comments
Good post. I learn something toitally new and challenging on sites
I stumbleupon onn a daily basis. It will always
be helpful to read through articles from other writers and
practice somethong from other sites.