How to Check for Exposed API Keys
Find leaked secrets before attackers do
TL;DR
TL;DR: Search your codebase with grep for common key patterns. Check git history for past commits. Inspect your browser bundle and network requests. Use automated tools like GitHub secret scanning or CheckYourVibe for continuous monitoring.
Common Key Patterns to Search For
API keys often follow recognizable patterns. Here are the most common ones:
| Service | Pattern | Example |
|---|---|---|
| Stripe Secret | sk_live_ or sk_test_ | sk_test_51H... |
| OpenAI | sk- | sk-proj-abc123... |
| Supabase Service | eyJ (JWT) | eyJhbGciOiJIUz... |
| AWS | AKIA | AKIAIOSFODNN7... |
| GitHub Token | ghp_ or github_pat_ | ghp_xxxx... |
| SendGrid | SG. | SG.xxxx... |
| Twilio | SK (32 chars) | SKxxxx... |
Method 1: Search Your Source Code
Use grep to search for hardcoded keys in your project:
# Search for common key patterns
grep -rn "sk_live\|sk_test\|sk-\|AKIA\|ghp_\|SG\." \
--include="*.ts" --include="*.js" --include="*.tsx" --include="*.jsx" .
# Search for generic patterns
grep -rn "api_key\|apiKey\|API_KEY\|secret\|password" \
--include="*.ts" --include="*.js" --include="*.json" .
# Exclude node_modules and other irrelevant directories
grep -rn "sk_live" --include="*.ts" --exclude-dir=node_modules .
Pro tip: Look for long random strings (32+ characters) that aren't obviously UUIDs or hashes.
Method 2: Check Git History
Keys might have been removed from current code but still exist in git history:
# Search entire git history for key patterns
git log -p --all | grep -E "sk_live|sk_test|api_key|AKIA"
# Search for specific file changes
git log -p -- .env
# Check if .env files were ever tracked
git log --all --full-history -- "*.env*"
# See all .env related commits
git log --oneline --all -- ".env*"
If you find keys in git history: Those keys should be considered compromised. Rotate them immediately, even if you think the repo is private. Then consider cleaning your git history with git filter-branch or BFG Repo Cleaner.
Method 3: Inspect Your Browser Bundle
Secret keys should never appear in client-side code. Check your production build:
# Build your app
npm run build
# Search the build output
grep -rn "sk_live\|sk_test\|sk-\|STRIPE_SECRET" .next/ dist/ build/
# For Next.js specifically
grep -rn "sk_" .next/static/
Check in the Browser
- Open your deployed site
- Open DevTools (F12) → Sources tab
- Press Ctrl+Shift+F (or Cmd+Shift+F on Mac) to search all sources
- Search for
sk_,api_key, or other patterns
Method 4: Monitor Network Requests
Keys shouldn't be sent from the browser to third-party services:
- Open DevTools → Network tab
- Use your app normally (login, submit forms, etc.)
- Click on each request and check Headers and Payload
- Look for Authorization headers or API keys in request bodies
Red flag: If you see secret keys (like sk_live_ ) being sent from the browser, your key is exposed to anyone using your site.
Method 5: Use Automated Tools
GitHub Secret Scanning
Enable in repo Settings → Security → Secret scanning. GitHub will alert you when it detects exposed secrets.
Pre-commit Hooks
Install tools that scan before each commit:
# Install detect-secrets
pip install detect-secrets
# Create baseline
detect-secrets scan > .secrets.baseline
# Add pre-commit hook
# In .pre-commit-config.yaml:
repos:
- repo: https://github.com/Yelp/detect-secrets
rev: v1.4.0
hooks:
- id: detect-secrets
args: ['--baseline', '.secrets.baseline']
CI/CD Scanning
Add secret scanning to your deployment pipeline:
# GitHub Actions example
- name: Scan for secrets
uses: trufflesecurity/trufflehog@main
with:
path: ./
base: main
head: HEAD
What to Do If You Find Exposed Keys
- Rotate immediately - Generate a new key in the service dashboard
- Update production - Deploy the new key
- Revoke the old key - Delete it from the service
- Check for abuse - Review logs for unauthorized usage
- Fix the root cause - Move to environment variables, update .gitignore
Are Supabase anon keys safe to have in client code?
Yes, Supabase anon keys are designed to be public. They only work with Row Level Security policies enabled. However, the service_role key must never be exposed.
What about Firebase config objects?
Firebase config (apiKey, authDomain, etc.) is designed to be public. It identifies your project but doesn't grant access. Your security comes from Firebase Security Rules, not hiding the config.
How often should I check for exposed keys?
Set up automated scanning to check on every commit. Additionally, do a manual review before any major release or when onboarding new team members.
Related guides:How to Hide API Keys · How to Rotate API Keys · How to Enable Secret Scanning