Hardcoded Secrets

Hardcoded secrets — API keys, database passwords, JWT signing keys — embedded in source code are one of the most common and impactful security mistakes. Once code is committed to a repository, the secret is compromised — even if it is removed in a later commit, git history preserves it forever.

# CRITICAL — never do this
DB_PASSWORD = "SuperSecret!2024"
API_KEY = "sk-live-abc123xyz789"

def connect():
    return psycopg2.connect(password=DB_PASSWORD)

Public GitHub repositories are continuously scraped by automated tools looking for secrets. Private repositories are also at risk from insider threats, stolen tokens, or accidental exposure.

The correct approach is to load secrets from the environment or a dedicated secret manager:

import os

# Load from environment
DB_PASSWORD = os.environ['DB_PASSWORD']
API_KEY = os.environ.get('STRIPE_API_KEY')

# Fail fast if required secret is missing
if not API_KEY:
    raise RuntimeError("STRIPE_API_KEY environment variable is required")

Secret managers (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, Azure Key Vault) provide audit logs, rotation, and fine-grained access control — much better than env vars for production.

Use secret scanning tools to catch leaks before they reach the repository:

• git-secrets — pre-commit hook that scans for patterns
• truffleHog — scans git history for high-entropy strings
• GitLeaks — configurable secret scanner for CI/CD
• GitHub secret scanning — automatic on all public repos

Add a .gitignore entry for .env files and never commit them. Use .env.example with placeholder values to document which variables are needed without revealing their values.

If a secret is ever committed — rotate it immediately. Treat the old credential as fully compromised from the moment of the first commit.