How to Check for Exposed API Keys

Share
How-To Guide

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:

ServicePatternExample
Stripe Secretsk_live_ or sk_test_sk_test_51H...
OpenAIsk-sk-proj-abc123...
Supabase ServiceeyJ (JWT)eyJhbGciOiJIUz...
AWSAKIAAKIAIOSFODNN7...
GitHub Tokenghp_ or github_pat_ghp_xxxx...
SendGridSG.SG.xxxx...
TwilioSK (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

  1. Open your deployed site
  2. Open DevTools (F12) → Sources tab
  3. Press Ctrl+Shift+F (or Cmd+Shift+F on Mac) to search all sources
  4. 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:

  1. Open DevTools → Network tab
  2. Use your app normally (login, submit forms, etc.)
  3. Click on each request and check Headers and Payload
  4. 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

  1. Rotate immediately - Generate a new key in the service dashboard
  2. Update production - Deploy the new key
  3. Revoke the old key - Delete it from the service
  4. Check for abuse - Review logs for unauthorized usage
  5. 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

How-To Guides

How to Check for Exposed API Keys