How to Find and Remove Hardcoded API Keys from Your Codebase

Why Hardcoded Secrets Are So Common

Developers hardcode secrets for understandable reasons: - It works immediately without any setup - Environment variables require more configuration - It is easy to forget a development key is still in the code - Copy-paste from documentation or Stack Overflow includes placeholder keys that get replaced with real ones

The result is that secrets end up in: - .env files committed to git (the most common) - Configuration files (config.json, settings.py) - Source code directly (strings in function calls) - Test files (especially integration tests against real APIs) - Comments (base64-encoded or "for reference only") - CI/CD configuration files

Method 1: grep with Regex Patterns

grep is available everywhere and requires no installation. These patterns catch the most common secret formats:

Save these as a shell script (check-secrets.sh) and run it before every commit.

Method 2: Search git History

The most important place to check is not the current working tree — it is your entire commit history. A secret removed from the current codebase might still be in a commit from six months ago.

If you find a secret in git history, it must be treated as compromised and rotated immediately — even if you are about to remove it from history.

Method 3: truffleHog

truffleHog is purpose-built for secret detection and uses both regex and entropy analysis to find secrets with fewer false positives than raw grep.

The --only-verified flag attempts to verify that detected secrets are actually valid by calling the relevant API. This dramatically reduces false positives.

truffleHog output

Method 4: ZeriFlow Advanced Scan

ZeriFlow''s Advanced Scan accepts a GitHub repository URL or a ZIP upload of your codebase and checks for:

• Hardcoded secrets using pattern matching and entropy analysis
• CVEs in your dependencies
• Insecure API patterns (open debug endpoints, missing authentication middleware)

This is the fastest way to get a comprehensive secret scan alongside a dependency and API pattern audit in a single report, without setting up CLI tools locally.

How to Remove Secrets from git History

Once you have found a secret in your git history, removing it from the working tree is not enough. The secret is still in every past commit. Anyone who clones your repository can find it.

The only correct response is: 1. Rotate the secret immediately (before cleaning history) 2. Clean the git history 3. Force-push the rewritten history

Using BFG Repo Cleaner (recommended)

BFG is faster and simpler than git-filter-repo for the common case of removing specific strings or files.

Warning: Rewriting git history is destructive. Everyone who has cloned or forked the repository must re-clone after you force-push. Coordinate with your team before doing this on a shared repository.

Removing an entire file from history

Using git-filter-repo (alternative)

Rotating Compromised Credentials

After any secret exposure, assume it has been used by an attacker. Rotation order:

Stripe

1. 1Dashboard → Developers → API Keys → Roll key
2. 2Update all production and staging environments
3. 3Verify webhooks are using the new key

AWS

1. 1IAM → Users → Security credentials → Deactivate old key → Create new key
2. 2Check CloudTrail for any suspicious activity using the old key
3. 3Update all services, update ~/.aws/credentials, rotate any infrastructure automation

GitHub Personal Access Token

1. 1Settings → Developer Settings → Personal Access Tokens → Delete old token
2. 2Generate new token with minimum required scopes
3. 3Check for any unauthorized repository access or workflow triggers

Database credentials

1. 1Update the database user password
2. 2Update all connection strings in all environments
3. 3Invalidate any existing connection pools (restart services)
4. 4Check database audit logs for unauthorized queries

General checklist after key rotation

• [ ] Old key is revoked or deleted (not just rotated)
• [ ] New key is stored only in environment variables or a secrets manager
• [ ] All environments (production, staging, CI/CD) are updated
• [ ] Relevant audit logs have been reviewed for unauthorized use
• [ ] The team has been notified

Preventing Future Secret Leaks

Pre-commit hooks with detect-secrets

GitHub secret scanning

Enable GitHub''s built-in secret scanning in your repository settings. It automatically scans pushes for over 200 secret patterns from major service providers and notifies you (and sometimes the service provider) immediately.

For public repositories, this is enabled automatically. For private repositories, it requires GitHub Advanced Security (included in GitHub Team and Enterprise plans).

Environment variable patterns

The correct pattern for every secret:

Add .env to .gitignore immediately when starting any project:

Use a .env.example file with placeholder values to communicate required environment variables without exposing real ones:

Summary

Finding and removing hardcoded API keys requires searching both your current working tree (grep, truffleHog) and your entire git history (git log -p). Any secret found in git history must be rotated immediately before rewriting history with BFG Repo Cleaner. Prevent future leaks with pre-commit hooks (detect-secrets), GitHub secret scanning, and always using environment variables for sensitive values. For a comprehensive automated scan of your repository including dependency CVEs and insecure API patterns, run an advanced scan at zeriflow.com.