GitHub is a Search Engine for Secrets — and Nobody Told You

infosecwriteups.com · Shah kaif · 1 day ago · research
quality 9/10 · excellent
0 net
GitHub is a Search Engine for Secrets — and Nobody Told You | by Shah kaif | in InfoSec Write-ups - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original GitHub is a Search Engine for Secrets — and Nobody Told You By Shah kaif | "Every leaked API key started as a commit someone thought was private." | LinkedIn Shah kaif Follow InfoSec Write-ups · ~7 min read · April 1, 2026 (Updated: April 1, 2026) · Free: Yes 💡R &qut;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 -q -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. 🙏 #bug-bounty #osint #bug-bounty-tips #bug-bounty-writeup #github-dork Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).