Leaked API keys and credentials are among the most common causes of security incidents — this guide covers systematic practices for preventing accidental exposure and responding when it happens.
Common Ways Credentials Leak
- Accidentally committed to a public (or even private, later-exposed) git repository
- Hardcoded in client-side JavaScript, visible to anyone viewing page source
- Logged accidentally in application logs
- Shared insecurely (plain text chat, email) between team members
Never Commit Secrets to Version Control
echo ".env" >> .gitignoreSee How to Manage Environment Variables and Secrets on a VPS — the foundational practice; use environment variables or a dedicated secrets manager, never hardcoded values in committed code.
Using Pre-Commit Hooks to Catch Accidental Secrets
pip install detect-secrets --break-system-packages
detect-secrets scan > .secrets.baselineTools like detect-secrets or git-secrets can scan commits before they're made, catching accidentally-included credentials before they ever reach version control history.
Scanning Existing Repository History for Leaked Secrets
pip install trufflehog --break-system-packages
trufflehog git file:///path/to/repoScans your entire git history (not just current files) for patterns matching common credential formats — useful for auditing an existing repository that may have accumulated exposed secrets over time, even if current code is clean.
Never Expose Secrets in Client-Side Code
Any credential included in JavaScript sent to a browser is visible to anyone inspecting the page — API keys needed for genuinely client-side use should be scoped with minimal necessary permissions (many API providers support restricted, public-safe key types specifically for this purpose) rather than using a full-access secret key client-side.
Avoiding Secrets in Application Logs
See Structured Logging Best Practices for Easier Debugging — audit logging code specifically for accidental credential inclusion; a surprisingly common and serious mistake, particularly in error/debug logging that captures full request details indiscriminately.
Using a Dedicated Secrets Manager for Production
See Docker Secrets Management: Handling Sensitive Data in Containers and general secrets management practices — a proper secrets manager (rather than plain environment variables) provides audit logging, rotation capability, and more granular access control for genuinely sensitive production credentials.
Responding to a Leaked Credential
- Immediately rotate/revoke the exposed credential — don't delay, since exposure duration directly correlates with risk
- Review logs/audit trails for any evidence of unauthorized use during the exposure window
- If committed to git, understand that simply deleting it in a new commit doesn't remove it from history — the credential remains exposed in git history regardless
- Investigate how the exposure happened and address the root cause to prevent recurrence
Setting Up Automated Secret Scanning in CI/CD
Integrate secret-scanning tools into your CI/CD pipeline (see How to Build a Simple CI/CD Pipeline with GitHub Actions) so any accidentally-committed secret is caught automatically before merge, not relying solely on manual vigilance.
Team Practices for Sharing Credentials Securely
Establish a clear, secure method for legitimately sharing credentials among team members when needed (a proper password manager with sharing features, for example) — discourage ad-hoc sharing via chat/email, which creates lasting, hard-to-audit exposure.
Common Errors
Discovered a credential has been exposed for an extended period — rotate immediately regardless of how long it's been exposed; don't assume "probably fine" based on no obvious signs of misuse, since sophisticated misuse isn't always immediately obvious.
Continue Reading
- How to Manage Environment Variables and Secrets on a VPS
- Docker Secrets Management: Handling Sensitive Data in Containers
- How to Handle a Data Breach: An Incident Response Framework
Browse more articles in Advanced Security & Compliance.
