By

| “Every leaked API key started as a commit someone thought was private.” | LinkedIn

💡 “GitHub Dorks: The Most Powerful OSINT Tool That’s Been in Plain Sight This Whole Time.”

🤯 I typed 4 words into GitHub’s search bar. Within 30 seconds, I was staring at a live AWS secret key belonging to a Fortune 500 company.
The key was active. The bucket was public. The data was real.
I did not hack anything. I just… searched GitHub the right way.

Most people use GitHub to browse repos and copy Stack Overflow code. Bug bounty hunters, red teamers, and OSINT investigators use it as a goldmine.

Today, I’m going to show you exactly how — with every dork, every operator, and every real-world use case I’ve personally used in my research.

This is the blog I wish existed when I started. Let’s go.

— — — — — — — — — — — — — — — PART 01 — — — — — — — — — — — — — — — — —

What Is a GitHub Dork?

A GitHub Dork is a crafted search query that uses GitHub’s advanced search operators to find sensitive, misconfigured, or interesting data that was accidentally committed to public repositories.

Think of it like Google Dorking — but instead of searching the web, you’re searching through millions of code commits, config files, environment variables, and developer mistakes.

GitHub dorks are used by:

Bug Bounty Hunters — to find exposed API keys, credentials, and endpoints in a target’s codebase or employee repos.
Red Teamers — to gather OSINT during recon: internal tools, employee emails, infrastructure details.
Security Researchers — to understand attack surface and proactively disclose secrets before bad actors find them.
Corporate Security Teams — to monitor their own org for accidental secret exposure.

— — — — — — — — — — — — — — — PART 02 — — — — — — — — — — — — — — — — —

GitHub Search Operators — The Master List

Before the dorks, understand the building blocks. These are GitHub’s native search operators. Combine them to create surgical queries.

💡 Pro Tip: Use GitHub’s Code Search at github.com/search?type=code — it searches file content, not just repo names. That's where the gold is.

— — — — — — — — — — — — — — — PART 03 — — — — — — — — — — — — — — — — —

Category 1: Exposed API Keys & Credentials

This is the big one. Developers push .env files, forget to .gitignore them, and secrets live forever in commit history.

AWS Keys

AKIAIOSFODNN7EXAMPLE in:file
"AWS_SECRET_ACCESS_KEY" in:file NOT example NOT test
filename:.env "aws_access_key_id"

Generic API Keys & Tokens

filename:.env "API_KEY="
"api_key" in:file language:python NOT test NOT demo
"Authorization: Bearer" in:file language:javascript
"private_key" extension:json

GitHub Personal Access Tokens (PAT)

ghp_ in:file
"github_token" in:file
filename:.env GITHUB_TOKEN

Stripe & Payment Keys

"sk_live_" in:file
"stripe_secret" in:file
filename:.env "STRIPE_SECRET_KEY"

Twilio / SendGrid / Mailgun

"TWILIO_AUTH_TOKEN" in:file
"SENDGRID_API_KEY" in:file
"MAILGUN_API_KEY" in:file

⚠️ Legal & Ethical Warning

Finding exposed credentials is one thing. Using them is a crime. Always follow responsible disclosure. Report to the vendor or company via their security contact or bug bounty program. Never access systems you’re not authorised to test. This guide is for authorized recon, bug bounty, and education only.

— — — — — — — — — — — — — — — PART 04 — — — — — — — — — — — — — — — — —

Category 2: Private Keys & Certificates

extension:pem "PRIVATE KEY"
extension:ppk "PuTTY-User-Key-File"
filename:id_rsa in:path
"BEGIN RSA PRIVATE KEY" in:file
"BEGIN OPENSSH PRIVATE KEY" in:file
filename:*.key in:path extension:key

Real talk: I’ve seen live SSH private keys committed by developers who thought they were only pushing to a private repo — but had forked it publicly, or the account privacy settings changed. History doesn’t lie.

— — — — — — — — — — — — — — — PART 05 — — — — — — — — — — — — — — — — —

Category 3: Database Credentials & Connection Strings

filename:.env "DB_PASSWORD="
"mongodb://" in:file "password"
"mysql://" in:file "username"
"postgres://" in:file "password"
"DATABASE_URL" in:file NOT localhost NOT 127.0.0.1
filename:database.yml "password:"
path:config filename:database password

Firebase / Supabase / NoSQL

"firebaseio.com" in:file "secret"
"SUPABASE_SERVICE_ROLE_KEY" in:file
"firebase_api_key" in:file

— — — — — — — — — — — — — — — PART 06 — — — — — — — — — — — — — — — — —

Category 4: Internal URLs, Endpoints & IPs

Companies often expose internal infrastructure by accident — staging environments, admin panels, and internal API docs.

org:TARGET "internal" in:file "http://10."
org:TARGET "staging" in:file "api"
org:TARGET filename:.env "INTERNAL_API_URL"
"admin_url" in:file org:TARGET
"192.168." in:file filename:.env org:TARGET
"http://localhost" in:file pushed:>2023-01-01

🎯 Bounty Tip

Combine org: with leaked internal URLs to map your target's infrastructure. You'll often find staging servers, CI/CD endpoints, and internal tooling domains that aren't in scope — but developers reference them from the in-scope repos.

— — — — — — — — — — — — — — — PART 07 — — — — — — — — — — — — — — — — —

Category 5: Config Files & Sensitive Filenames

Filenames are a treasure map. These are the ones most likely to contain gold:

filename:.npmrc "_authToken"
filename:.dockercfg "auth"
filename:wp-config.php "DB_PASSWORD"
filename:settings.py "SECRET_KEY"
filename:config.php "password"
filename:application.properties "password"
filename:appsettings.json "ConnectionStrings"
filename:.htpasswd
filename:shadow in:path
filename:passwd in:path
filename:credentials extension:xml
filename:.bash_history

— — — — — — — — — — — — — — — PART 08 — — — — — — — — — — — — — — — — —

Category 6: Target-Specific Recon (Bug Bounty Gold)

When you’ve got a specific target in a bug bounty program, this is where GitHub dorks become devastatingly effective.

Search by Organisation Name

org:TARGET_ORG filename:.env
org:TARGET_ORG "secret" in:file pushed:>2024-01-01
org:TARGET_ORG "password" in:file language:yaml
org:TARGET_ORG extension:pem

Search by Domain / Product Name

"targetdomain.com" in:file "password"
"@targetdomain.com" in:file "api"
"targetdomain.com" filename:.env
"targetproduct" "api_key" in:file

Find Employee Repos (Leaked Corp Secrets)

"@targetdomain.com" in:file pushed:>2023-01-01
"targetcompany internal" in:file
user:employee_github_username filename:.env

The insider trick: Employees fork company repos to their personal accounts and add credentials locally. That personal fork is now public. Search by email domain, not just org name.

— — — — — — — — — — — — — — — PART 09 — — — — — — — — — — — — — — — — —

Automate It: Tools That Use GitHub Dorks

Doing this manually is fine for targeted recon. But for scale, these tools automate GitHub dork searches:

Quick Start: GitDorker

git clone https://github.com/obheda12/GitDorker
cd GitDorker
pip3 install -r requirements.txt
python3 GitDorker.py -t <GITHUB_TOKEN> -q <TARGET> -d dorks/alldorks.txt

Tip: Also Try Betterleaks…..

— — — — — — — — — — — — — — — PART 10 — — — — — — — — — — — — — — — — —

The Methodology: How I Use GitHub Dorks in Real Recon

Here’s my actual workflow when starting a new bug bounty target:

1️ Identify the org — Find the company’s GitHub org name. Check their website, LinkedIn, job postings.

2️ Find employee accounts — Search for emails "@company.com" in GitHub profiles. List their personal accounts.

3️ Org-level sweep — Run org:TARGET with top dorks: .env, password, api_key, secret.

4️ Employee repo sweep — Same dorks on each employee’s personal account. This is where most leaks hide.

5️ Commit history mining — Use TruffleHog on any interesting repos to scan every commit, not just current files.

The move everyone misses: Even if a secret was deleted from a file, it still exists in commit history. Tools like TruffleHog dig through every git log entry. A secret committed once lives forever unless keys are rotated.

Found This Useful?

Clap 50 times, share with your bug bounty squad, and follow me on Medium for more write-ups on OSINT, web vulns, and real-world hacking stories.

Got a GitHub dork find you want to share? Drop it in the comments. Let’s build the ultimate community dork list. 👇

Disclaimer: All techniques described in this article are for authorized security testing, bug bounty programs, and educational purposes only. Accessing systems or data without explicit permission is illegal. The author is not responsible for misuse. Always hunt responsibly. 🙏