Google Dorks Cheat Sheet (2026 Guide)

If you‘ve ever had trouble finding exactly what you needed on Google, you‘re not alone.

For years, underground hackers have been refining advanced Google search operators to find valuable information that has accidentally been indexed by search engines.

Google Dorking isn‘t limited to use on Google search engines—any search engine can index information from specific websites, giving hackers a leg up in their reconnaissance cyberattack planning.

Let‘s dive into how simple search terms are calling for improved dorking security practices and what cybersecurity professionals can do to protect their most valuable information.

How does Google Dorking work?

Google Dorking is an advanced technique using search engine functionality that allows you to find specific information on any indexed website. To find indexed content, specific search operators (or search terms) are needed to locate the information.

Using these search query functions can be a goldmine for both cybersecurity professionals and hackers.

On the one hand, security professionals can locate and remedy exposed databases or potentially leaked credentials—but on the other hand, hackers can use these same search techniques for reconnaissance missions to launch attacks.

Why is Google Dorking important for cybersecurity?

Google reaches into all corners of the internet, able to index and cache web content, even in areas typically off-limits to regular users.

By using Google Dork techniques, cybersecurity experts can retrieve hidden or restricted content for analysis, helping your team locate vulnerabilities within your sites before a breach occurs.

An X post sharing various Google Dorking commands for Bug Bounty hunting.

Ethical hackers can use Google Dorks to:

  • Perform cybersecurity testing to locate administrative login pages or exposed database files and test their security.
  • Scan for sensitive files to ensure company secrets aren‘t mistakenly published and indexed online.
  • Find leaked credentials that could open an organization to an attack.
  • Detect phishing websites that may be impersonating the brand.
  • Perform vulnerability assessments by locating misconfigured servers or exposed login pages.
  • Meet compliance standards and data privacy checks.

While dork queries are a potent tool for cybersecurity professionals, there are ethical and legal considerations organizations must be aware of.

Dorking must align with Google‘s Terms of Service to be considered legitimate and legal. Certain activities, such as bypassing paywalls or authorization pages, cross the boundaries into intellectual property theft and can leave the business liable.

Top 20 most useful Google Dorking commands

The following Google Dorking techniques give your security researchers an edge when it comes to information gathering. Using a Google Dork cheat sheet gives security teams a starting point to find potentially damaging data leaks or other threats.

For a more extensive Google Dorks list, head to the Google Hacking Database to find hundreds of specific commands and known exploits to take your research even further.

CommandFunction
site:Restricts search results to a specific domain (e.g., site:example.com).
filetype:Filters results by a specific file type (e.g., filetype:xlsx).
inurl:Searches for specific text within URLs.
intitle:Finds pages with specific text in the title (e.g., intitle:index).
intext:Finds pages containing a specific word in the body text.
cache:Displays cached versions of web pages.
allintitle:Finds pages with multiple keywords in the title.
allintext:Searches for multiple words within page content.
allinurl:Finds pages with multiple keywords in the URL.
link:Finds web pages linking to a specific URL.
related:Displays pages related to a specific URL.
info:Provides details about a website, including cache and similar pages.
ext:Finds a specific file extension.
phonebook:Searches for phone numbers and contact information for a person or business.
inanchor:Searches for keywords within the anchor text of links on a webpage.
keyword:Excludes results containing a specific word.
inurl: loginLocates login pages.
inurl: adminSearches for admin panels or login pages.
inurl:php?id=Identifies pages with query parameters.
intitle:”dashboard”Finds exposed dashboards or panels.

As you can see, Google Dorking is a double-edged sword. Dork queries can be used by security researchers to locate and remedy vulnerabilities, but also by hackers looking for a foothold.

How do attackers use Google Dorks to find vulnerabilities?

Hackers are clever—they use the same tools designed to protect in adversarial ways. By using the same dorking search queries, they can gain access to restricted areas of sites simply by using Google search.

Cybercriminals exploit Google Dorks to:

  • Identify vulnerable login pages for brute-force attacks.
  • Locate exposed databases and sensitive directories.
  • Access confidential documents like financial records or contracts.
  • Find employee data, including names, emails, or phone numbers.
  • Research technology stacks such as WordPress, Apache, or outdated software with known vulnerabilities.
  • Identify vulnerable servers for later malware attacks.
An X post sharing how hackers can gain access to sensitive customer data using Google Dorking commands.

Google Dork examples

Understanding how hackers may use Google Dorks is imperative for preventing attacks and staying one step ahead.

Let‘s dive into some examples of Google Dorking commands to better understand how hackers pose a threat.

1. Restricted login portals

inurl:login site:example.comintitle:"admin login"

  • Hackers can use inurl:login to search only the target site for any logins that may be exposed.
  • The intitle: "admin login" command shows all pages that contain admin logins.
  • The risk: Google search can index admin login pages, giving hackers an opportunity to launch brute-force attacks and gain entry.

2. Open directories

intitle:"index of /" site:example.cominurl:ftp

  • The intitle: "index of/" command will show directories linked to a specific site.
  • Adding inurl:ftp will locate publicly accessible FTP directory listings indexed by a search engine.
  • The risk: If a site had misconfigured permissions, internal directories containing sensitive information are published publicly, putting the company at risk.

3. Exposed SQL databases

filetype:[database_format] "backup" "internal"

  • Using the filetype command will locate exposed database files that contain the parameters “backup” or “internal.”
  • The risk: Hackers can gain access to sensitive files intended for internal use or recovery backups. In case of a breach, organizations will face data loss and reputational damage.

4. Full tech stack

inurl:phpinfo.phpintitle:"Apache2 Ubuntu Default Page"inurl:.git site:example.com

  • inurl searches for PHP functions that contain detailed server configuration information, including pathways, system architecture, and extensions.
  • From there, intitle can look specifically for Apache on Ubuntu, indicating a server isn‘t fully deployed yet.
  • inurl:.git looks for .git folders that contain the internal repository structure.
  • The risk: Cybercriminals can locate misconfigurations in the system architecture, forgotten servers, source code leaks, and other sensitive data like API keys, deployment scripts, and internal commands. Having your tech stack indexed online puts the whole organization at risk.

5. Leaked credentials and tokens

intext:"password=" filetype:txt"DB_PASSWORD" filetype:env"aws_access_key_id" filetype:env

  • The intext command locates all files that contain “password=” finding passwords stored in plaintext.
  • The variable"DB_PASSWORD" locates database credentials stored in .env files.
  • "aws_access_key_id" finds credentials stored in AWS to access S3 buckets or modify cloud databases.
  • The risk: When credential files and databases are indexed online, hackers can use this to their advantage, deploying ransomware, reselling credentials online, or stealing company secrets.

6. Published sensitive files

filetype:sql "INSERT INTO" "password"filetype:log "root" | "admin"

  • filetype:sql searches for SQL database dump files indicating a database backup.
  • filetype:log looks for log files that contain the word “root" or “admin” to find server activity.
  • The risk: SQL dumps can be used by hackers to harvest credentials or perform an account takeover (ATO). Finding an organization‘s log files can reveal legitimate admin login attempts, internal IP addresses, and server paths, leading to targeted brute-force attacks.

7. Exposed API keys

filetype:[config] "[API_KEY_INDICATOR]" site:[developer_domain]

  • The filetype:[config] query searches for configuration files containing the keyword "[API_KEY_INDICATOR]" to reveal API keys.
  • The risk: Cybercriminals can quickly find an organization‘s API keys to access internal APIs or cloud infrastructure, leading to impersonation and further damage.

How has Google Dorking changed in 2026?

With all the hype around Google Dorking, professionals are now taking the reins, turning a once-underground cybercrime practice into a valuable tool for cybersecurity professionals.

A YouTube video detailing the newest Google Dorking commands commonly used in 2026.

Here are the biggest changes in Google Dorking for 2026:

1. Automated tooling

Google Dorking in 2026 is far less manual than it used to be. With automated generative tools like Dorklist, it‘s quicker than ever for cybersecurity professionals and hackers to find commands.

2. Better community organization

Online communities like those on GitHub have come together to share resources. Finding step-by-step dorking instructions for various use cases has made breaching or securing web servers easier than before.

3. Greater variety of specialized categories

The expansion of cloud and API infrastructure in recent years has driven a need for specialized dorking categories. DorkFinder‘s 2026 categories reflect this change, showing a wider attack surface than in previous years.

4. Increase in structured OSINT education

With more awareness of Open Source Intelligence (OSINT) education, Google Dorking commands are becoming a more formal practice for cybersecurity professionals. Taking away the guesswork, professionals can now adapt dorking into a systematic approach, helping security teams map digital footprints and integrate them into recon pipelines.

What types of sensitive information are commonly exposed through Google Dorks?

Protecting web pages against Google Dorking abuse is key to reducing security risks. While it‘s common practice to implement web application firewalls and secure authentication, human error can sometimes cause sensitive information to leak through the cracks.

Here‘s a summary of the most common types of sensitive data that can end up being indexed by crawlers.

CategoryExplainerMitigation
Databases and backupsIn the modern attack chain, databases and backup files can be indexed by Google and exposed if they‘re not properly configured.

This includes: • SQL database dumps. • Backup files (.bak, .old, .zip). • Configuration files with credentials. | Treat search engines as part of your attack surface and build appropriate controls.

• Store backups outside the web root. • Avoid manual exports to web‑accessible folders. • Use robots.txt files to disallow sensitive paths. • Scan servers for .sql and related files. • Continuously monitor your domain for misconfigured directories. | | Credentials | In some cases, developers accidentally leave passwords inside source code or configuration documents. If these files are inside a web-accessible directory, Google crawlers can index them.

Dorking commands can locate: • Hard‑coded passwords. • API keys. • Admin credentials. • Login portals unintentionally indexed. | To combat credential leaks, be vigilent about what is available in web-accessible directories and databses.

• Use secret management for secure credential storage. • Don‘t store credentials within source code. • Use file‑system permissions to restrict access. • Add noindex to headers of login pages. | | Sensitive documents | Sensitive documents like PDFs (pdf), documents (docs), and spreadsheets (xls), can end up being indexed by Google when they‘re placed in the wrong directory or a forgotten subdomain.

This risks exposing: • Email formats, enabling attackers to send convincing phishing emails. • Project timelines, so attackers know when employees may be distracted. • Authentication hints, making account takeover more effective. • Metadata, giving attackers insight into company indentities. • Internal URLs, exposing company pathways to hackers. | To mitigate the risk of internal files being exposed, be sure to tightly control what Google crawlers have access to.

• Use firewalls, VPNs, or IP allowlists for admin or internal paths. • Add Disallow: rules in robots.txt files. • Include <meta name="robots" content="noindex"> to sensitive pages. • Review cloud storage buckets for public permissions. • CI/CD secret‑scanning to detect exposed files. | | Personal information | Information about employees and stakeholders can be leaked through Google Dorks when files and pages are placed in public spaces.

Dorking can uncover: • Employee names. • Phone numbers. • Email addresses. • Social media data. | To prevent personal information from circulating online:

• Ensure all employee data is stored outside the web root. • Use role‑based access controls for HR, finance, and internal files. • Review cloud storage permissions regularly. • Encrypt all sensitive data like HR and financial reports. • Use defensive Google Dorking to find exposed data before hackers do. | | Admin panels and dashboards | When admin panels and dashboards end up on Google, they provide attackers with direct access to the internal controls of an application, giving them a gateway to the entire system.

Google dorking can enable hackers to: • View app logs. • Trigger builds. • Modify configurations. • Execute malicious code. | To protect admin panels and dashboards, be sure to consider:

• Required login for all admin routes. • Enforce multi-factor authentication (MFA). • Rename default admin pathways with non-guessable keywords. • Disable unused admin endpoints. • Shut down unused staging or test environments. • Restrict API endpoints. |

How can security teams integrate Google Dorks into their reconnaissance workflow?

Google Dorking can help cybersecurity professionals understand what may already be exposed on Google, empowering better defensive efforts.

Start integrating Google Dorking into your recon workflows by:

  1. Building a defined dorks library: Create your own Google Dorking cheat sheet to store, tag, and refine high-value dorks for reuse across cases and teams.
  2. Automating dork execution: With OSINT automation tools, it’s easier to review and refine queries, maintaining control over every search you run.
  3. Using dorks to map the organization‘s external footprint: Dorking can help identify assets that may be exposed, like forgotten subdomains and hosting environments. Accounting for them will keep you a step ahead of hackers.
  4. Integrating dorking into security hygiene: Defensive dorking can include weekly scans for high-risk assets, monthly sweeps for domains, and after major deployments to catch exposures early.
  5. Using dorking in red-teaming exercises: Penetration testing and red-teaming with Google Dorks simulates an attacker‘s reconnaissance to keep security efforts grounded in real-world scenarios.
  6. Training developers and content owners: Educate employees to reduce accidental uploads, misconfigured storage, and the real dangers of search engine indexing of sensitive environments.

FAQs

Open Source Intelligence (OSINT) leverages publicly available information to identify threats and vulnerabilities. Google Dorking can be a potent tool in your OSINT arsenal—able to sift through vast amounts of data with specific, codified commands.
When using advanced search operators for OSINT research, be sure to follow ethical considerations and legal guidelines. Cybersecurity researchers should never attempt to access non-public systems, bypass authentication, or exfiltrate data without proper authorization.

Robots.txt files act like instructions that tell search engine crawlers what they’re allowed to access on a website.
For defensive Google Dorking, Robots.txt files are essential to blocking search engine crawlers from indexing sensitive directories.
It‘s important to remember that Robots.txt files are requests, not a security barrier. Google can still index pages containing Robots.txt files indirectly. For sensitive files, the best practice is to keep them offline or in places where they are not publicly reachable.

Search engines index more information than you might realize. Public social media account activity can be indexed by search engine operators and located later with Google Dorking techniques.
Even if you delete the post, cached versions of the post, along with valuable metadata, can still be found.
Social media data creates OSINT vulnerabilities, such as exposing employees’ birthdates, locations, employer details, travel plans, and contact information, like emails and phone numbers.

HTML local storage is a browser‑side storage mechanism that lets websites save data on a user’s device. It‘s usually used for UI preferences or caching small amounts of data.
However, HTML local storage can become a risk when the developer stores sensitive data like API keys, token IDs, or source maps within local storage. Mistakes like these cause search engine algorithms to index information that should never be made public.

Wrapping up

Having the proper access controls in place is essential for protecting against Google Dorking misuse.

When using dorking commands for security research and vulnerability fixes, be sure to take proactive security measures against hackers using the same techniques to their advantage.

Manage your external-facing assets before they‘re leaked and distributed on the dark web. With CybelAngel, you can locate shadow assets indexed by search engines and prioritize based on real-world risks.

About the author