API Key Security Checklist Before Going to Production

Published March 9, 2026 · 8 min read · By SPUNK LLC

Shipping to production is exciting, but it is also the moment when API key security goes from "nice to have" to "business critical." A leaked production key can result in data breaches, financial losses, and compliance violations within minutes. Use this 15-point checklist to verify your credential security before every production deployment.

Storage and Configuration

1 No hardcoded credentials in source code

Search your entire codebase for API keys, tokens, passwords, and connection strings. Use tools like gitleaks, trufflehog, or detect-secrets to scan automatically. Check config files, test files, documentation, and comments — keys hide in unexpected places.

2 Secrets stored in a dedicated secrets manager

Production keys must live in a secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault, or Doppler) — not in environment variables on disk, not in config files, and not in CI/CD platform settings. The secrets manager provides encryption, access logging, and rotation capabilities.

3 Different keys for each environment

Production, staging, and development must use completely separate API keys. Never share keys across environments. A compromised development key should not grant access to production data. Verify this by checking that key prefixes or identifiers differ per environment.

4 .gitignore covers all secret files

Your .gitignore must include .env, .env.local, .env.production, *.pem, *.key, credentials.json, and any framework-specific secret files. Run git ls-files to verify no secret files are tracked.

Access Control

5 Least privilege permissions applied

Every API key should have the minimum permissions required for its function. If a service only reads from S3, its key should not have write or delete permissions. Review the IAM policy or API key scope for every credential in your system.

6 IP and domain restrictions configured

Where supported, restrict API keys to specific IP ranges or domains. Google Cloud API keys, Stripe restricted keys, and many other providers support IP allowlisting. This limits damage even if a key is leaked.

7 Service accounts used instead of personal keys

Production should never use a key tied to an individual developer's account. Create dedicated service accounts with their own credentials. This ensures production access is not affected when employees leave or change roles.

Rotation and Lifecycle

8 Rotation schedule documented and automated

Define a rotation schedule for every production key: 30 days for high-risk keys (payment, database), 60 days for medium-risk, 90 days for low-risk. Automate rotation using your secrets manager's built-in rotation features or a custom Lambda/CronJob.

9 Rotation tested in staging first

Before going live, perform at least one complete key rotation in staging. Verify that the application handles the transition smoothly, that no service breaks, and that the old key is properly deactivated. Document any issues discovered.

10 Dual-key support implemented

Your application should support accepting two active keys simultaneously during rotation windows. This enables zero-downtime rotation. Test this by having both an old and new key active and verifying the application works with either.

Monitoring and Detection

11 API usage monitoring active

Set up monitoring for all API key usage patterns. Alert on unusual volumes, requests from unexpected geographic regions, calls to endpoints the key should not access, and usage outside normal business hours. Most API providers offer usage dashboards and webhook notifications.

12 Pre-commit hooks installed for all developers

Every developer with repository access must have pre-commit hooks that scan for secrets. Use gitleaks, git-secrets, or detect-secrets as a pre-commit hook. Make this part of your onboarding checklist. Also enable server-side scanning with GitHub push protection.

13 Keys excluded from application logs

Verify that API keys are never written to application logs, error tracking services (Sentry, Datadog), or debug output. Search existing logs for key patterns. Configure your logging framework to redact known secret patterns automatically.

Incident Response

14 Key compromise runbook documented

Write a step-by-step runbook for responding to a key compromise: (1) revoke immediately, (2) generate replacement, (3) deploy new key, (4) assess unauthorized usage, (5) notify affected parties, (6) post-incident review. Store this in a location accessible to the on-call team. Test it with a tabletop exercise at least once.

15 Backup access path confirmed

Verify that if a primary key is revoked, there is a documented process to generate and deploy a replacement without requiring access to the compromised key. This includes ensuring the secrets manager itself is accessible via a separate authentication path (SSO, hardware MFA, break-glass account).

Quick Verification Commands

Run these commands before every production deployment to catch common issues:

# Scan the codebase for secrets
gitleaks detect --source . --verbose

# Check .gitignore coverage
git ls-files | grep -iE '\.(env|pem|key|p12)$'

# Verify no AWS keys in the codebase
grep -rn 'AKIA[A-Z0-9]{16}' --include='*.py' --include='*.js' --include='*.ts' .

# Check for common secret patterns
grep -rn 'sk_live_\|sk_test_\|ghp_\|glpat-\|xoxb-\|xoxp-' .

# List all environment variables that might contain secrets
env | grep -iE 'key|secret|token|password|credential' | cut -d= -f1

Automation: Adding to CI/CD

Integrate this checklist into your CI/CD pipeline so it runs automatically on every pull request and deployment:

# GitHub Actions example
name: Security Checks
on: [pull_request]

jobs:
  secret-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Run gitleaks
        uses: gitleaks/gitleaks-action@v2
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Check for hardcoded credentials
        run: |
          # Fail if any common key patterns are found
          if grep -rn 'AKIA[A-Z0-9]\{16\}\|sk_live_\|-----BEGIN.*PRIVATE KEY-----' \
            --include='*.py' --include='*.js' --include='*.ts' --include='*.yaml' .; then
            echo "ERROR: Potential secrets found in source code"
            exit 1
          fi
Key Takeaway

This checklist is not a one-time exercise. Run it before every production deployment and audit it quarterly. The most dangerous keys are the ones you forgot about — the test key that became production, the personal access token that was never rotated, the credential that slipped past code review. Systematic checking catches what human review misses.

Recommended Tools and Resources

Strengthen your production security posture with these tools and books: