Introduction

GitHub sometimes contains a lot of stuff — developers put their work, examples, scripts, and many of them accidentally leave sensitive things inside repos. What you find can be very dangerous depending on the type and privileges. But beware: what you find on GitHub is not always the end of the story — sometimes it is the DOOR to bigger problems elsewhere. It might be just a small leak, but if a key or token has wide permissions, you might find yourself facing cloud servers, databases, or pipelines that can perform deploys. Here I'll tell you, in general, where to look, and some organized tips you must follow.

What to look for (general)

  • Configuration files like .env, config.*, settings.*
  • Keys and tokens: API_KEY, AWS_ACCESS_KEY_ID, Authorization: Bearer ...
  • CI/CD files and workflows like .github/workflows/*
  • SSH keys / .pem files accidentally committed
  • Sensitive data about customers or employees (PII)
  • Database connection strings (postgres://, mysql://, mongodb+srv://)
  • And of course much more — you're looking for things the company wouldn't want published or used

Dorks (use in GitHub search)

Note: These are not everything — you can add or remove as you like; the important part is the idea.

Emails

org:(org_name_in_github) "@gmail.com"
org:(org_name_in_github) "@yahoo.com"
org:(org_name_in_github) "@hotmail.com"
org:(org_name_in_github) "@(your_target_email)"

Tokens / Secrets / API Keys

org:(org_name_in_github) "AWS_SECRET_ACCESS_KEY"
org:(org_name_in_github) "AWS_ACCESS_KEY_ID"
org:(org_name_in_github) "Authorization: Bearer"
org:(org_name_in_github) "api_key" language:json
org:(org_name_in_github) "secret" language:yaml
org:(org_name_in_github) "PRIVATE_KEY"
org:(org_name_in_github) "api_key"
org:(org_name_in_github) "Token"
org:(org_name_in_github) "secret"
org:(org_name_in_github) "client_secret"
org:(org_name_in_github) "password" language:env
org:(org_name_in_github) filename:.env
org:(org_name_in_github) filename:.npmrc
org:(org_name_in_github) filename:.dockercfg
org:(org_name_in_github) filename:.bash_history
org:(org_name_in_github) "BEGIN RSA PRIVATE KEY"

Config Files

org:(org_name_in_github) filename:config.js
org:(org_name_in_github) filename:settings.py
org:(org_name_in_github) filename:application.properties
org:(org_name_in_github) filename:credentials.json
org:(org_name_in_github) filename:firebase.json

GitHub Actions

org:(org_name_in_github) filename:.github/workflows
org:(org_name_in_github) "secrets." language:yaml
org:(org_name_in_github) "GITHUB_TOKEN"
org:(org_name_in_github) "CI_SECRET"

Hardcoded credentials (in code)

org:(org_name_in_github) "username" "password"
org:(org_name_in_github) "username"
org:(org_name_in_github) "password"
org:(org_name_in_github) "db_password"
org:(org_name_in_github) "mongodb+srv://"
org:(org_name_in_github) "postgres://"
org:(org_name_in_github) "mysql://"

If you want to find Admin Panels too

org:(org_name_in_github) "admin"
org:(org_name_in_github) "admin" in:url
org:(org_name_in_github) "admin" in:path
org:(org_name_in_github) "dashboard" in:url
org:(org_name_in_github) "control panel"
org:(org_name_in_github) "login" filename:config.js
org:(org_name_in_github) "admin_url"
org:(org_name_in_github) "site_url"

Tips

1. Check the scope first

Look at the program / bounty scope: many companies do not accept reports about things from GitHub if they are outside the org or out of scope.

2. Focus on the company's org

  • Always search inside the target company's organization.
  • Some people search everything — maybe a contractor or private dev uploaded something outside the org (Personally, I don't work on those).

3. Avoid words/segments that indicate it's an example (could kill your report)

If a triager sees the repo looks like an example or local setup, they might mark it as NA without even reading your report.

Examples:

test, example, dummy, sample, demo , local (sometimes it's important so keep focus)

  • README or docs containing phrases like: "this is a sample/test project" or "for demo purposes only"
  • Directories such as: examples/, sandbox/, docs/examples/, etc.

4. Check history before reporting

If the item is old (a commit from years ago) and the repo looks inactive, and you're not sure if it's important — don't rush to report.

5. Verify carefully — avoid sensitive experiments

  • Try to verify non-destructively.
  • If it's too sensitive, don't experiment — just send a responsible report.

Conclusion

This is a useful and easy check and you should look for it in any program that allows it — people really forget secrets inside repos. I'll make a video soon where I do this practically — wait for it and I'll see you in the video.

Follow Me

If you found this useful, follow me for more:

my username everywhere: @metwallysec

I share practical bug hunting tips, write-ups, and tutorials.

#BugBounty #GitHubLeaks #InfoSec #EthicalHacking #AppSec #BugHunting #InformationDisclosure #GitHubSecurity #CyberSecurity #HackTheBox #BugBountyTips