Secret Scanning: Finding Exposed API Keys, Tokens, and Credentials

Exposed credentials are some of the most impactful findings in bug bounty and penetration testing. A single leaked AWS key can result in full cloud account compromise. A GitHub token with repo write access can enable supply chain attacks. This guide covers where secrets get exposed, how to find them, and what to do when you do.

Where Secrets Get Exposed

GitHub and Public Repositories

The most common source of exposed secrets. Developers accidentally commit .env files, hard-coded credentials in source code, and configuration files with API keys. Even deleted files remain in git history.

JavaScript Files

Client-side JavaScript frequently contains:

• API keys for third-party services (Google Maps, Stripe, Twilio)
• Firebase configuration objects with project credentials
• Hard-coded endpoint URLs revealing internal infrastructure
• Feature flags exposing internal admin functionality

HTTP Responses

Applications return secrets in responses more often than you'd expect:

• API responses including server-side secrets or tokens not intended for client use
• Debug endpoints (/debug, /env, /actuator/env) leaking environment variables
• Error responses including stack traces with connection strings
• Verbose logging endpoints returning internal tokens

Docker Images

Docker image layers are additive — even if a secret is removed in a later layer, it persists in the earlier layer and is extractable:

# Pull a public image and inspect layers
docker pull targetapp:latest
docker history --no-trunc targetapp:latest

# Extract a specific layer to look for secrets
docker save targetapp:latest | tar xO | tar xz

Mobile APKs

Android APK files frequently contain hard-coded API keys, certificate pins, and internal API endpoints:

apktool d target.apk -o decompiled/
grep -r "api_key\|apikey\|secret\|token\|password" decompiled/

Tools for Scanning

trufflehog

TruffleHog detects secrets by entropy analysis and regex patterns. It supports Git repos, S3 buckets, GitHub organizations, and file system scanning:

# Scan a GitHub organization
trufflehog github --org=targetcompany --only-verified

# Scan a specific repo including history
trufflehog git https://github.com/target/repo --only-verified

# Scan local filesystem
trufflehog filesystem /path/to/directory

The --only-verified flag attempts to verify discovered secrets are still active before reporting, reducing false positives significantly.

gitleaks

Gitleaks is fast, customizable with TOML config files, and has excellent support for CI/CD integration:

# Scan a local repo
gitleaks detect --source /path/to/repo -v

# Scan with custom config
gitleaks detect --config .gitleaks.toml --source .

# Scan a remote repo
gitleaks detect --source https://github.com/target/repo

detect-secrets

Yelp's detect-secrets is particularly good for baseline-based scanning — it creates a baseline of known false positives so you only see new secrets in CI:

detect-secrets scan > .secrets.baseline
detect-secrets audit .secrets.baseline

Use the Secret Scanner to paste HTTP response bodies, JavaScript files, or configuration snippets and identify credential patterns across dozens of secret types.

GitHub Dork Patterns

# GitHub search operators for secret hunting
site:github.com "AKIA" extension:env         # AWS access keys
site:github.com "sk-" extension:py           # OpenAI API keys
site:github.com "-----BEGIN RSA PRIVATE KEY" # Private keys
site:github.com filename:.env "DB_PASSWORD"
site:github.com "api.example.com" password
site:github.com org:targetorg "secret_key"
site:github.com org:targetorg filename:config.yml password

# GitHub code search API
curl -H "Authorization: Bearer <token>"   "https://api.github.com/search/code?q=AKIAIOSFODNN7EXAMPLE+org:targetorg"

Shodan for Exposed Services

# Find exposed environment variable endpoints
http.title:"Environment Variables" org:"Target Corp"

# Redis without authentication (often contains session tokens)
product:redis -auth org:"Target Corp"

# Elasticsearch with data
product:"Elastic" port:9200 org:"Target Corp"

# Jenkins instances (often hold deployment credentials)
http.title:"Dashboard [Jenkins]"

The Recon Hub integrates with Shodan to surface exposed services and infrastructure misconfigurations as part of the recon workflow.

Manual Techniques

• View source — Ctrl+U in browser, search for "key", "token", "secret", "password", "api"
• Burp scope search — search HTTP history for common secret patterns using regex: AKIA[0-9A-Z]{16} for AWS, ghp_[A-Za-z0-9]{36} for GitHub tokens
• JS file analysis — extract all JS URLs from a site, download them, and run gitleaks or trufflehog against the output

AWS Key Verification Without Unauthorized Access

When you find what looks like AWS credentials, you can verify they're valid and check their permissions without unauthorized access:

# Check identity without accessing any resources
aws sts get-caller-identity   --access-key-id AKIAIOSFODNN7EXAMPLE   --secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# This returns the account ID and user/role ARN — proves the key is valid
# without accessing any data, logging any service calls, or causing any harm

Use this one-time validation to confirm the key is live for your report, then stop. Do not enumerate permissions, access any S3 buckets, or use the credentials for any further access.

Responsible Disclosure

When you find real, valid secrets:

1. Stop using them immediately after confirming they're valid
2. Report with impact evidence — include the aws sts get-caller-identity output or equivalent verification
3. Never store or share credentials beyond what's needed for the report
4. Note GDPR/regulatory implications — exposed credentials covering personal data constitute a potential data breach and may require notification under GDPR Article 33 (within 72 hours)

Document your findings with the Pentest Findings Documenter and score severity using the CVSS Calculator — exposed valid AWS keys with broad permissions typically score 9.8–10.0.