Secrets Management
Date: 2026-08-17
Handling API keys, tokens and credentials so they don’t leak — and rotating them when they do. The rule that surprises people is that a secret committed to a repository stays compromised after you delete it, because git keeps everything.
A secret is any value that grants access — API keys, database passwords, signing keys, tokens, certificates. Secrets management is how they’re stored, distributed, rotated and revoked.
Deleting a committed secret does nothing
commit A adds API_KEY=sk_live_...
commit B removes it
↓
git history still contains commit A
anyone with the repo can read it
forks, clones, CI caches, and mirrors
all have it
The only correct response to a committed secret is to rotate it. Rewriting history helps, and it does not un-copy anything. Assume anything pushed to a remote — especially a public one — is compromised within minutes; automated scanners watch public repositories continuously.
1 ROTATE the credential immediately
2 then clean history if you like
3 check logs for use of the old one
Step 1 first. Cleaning history while the key is still valid is fixing the wrong problem.
Where secrets belong
NEVER
in source code
in a committed .env
in client-side JavaScript
in a URL (logged everywhere)
in a log line
in an error message shown to users
in an analytics event
ACCEPTABLE
environment variables, injected at
runtime
a platform's secret store
a dedicated manager — Vault, AWS/GCP
secret managers
encrypted files with the key held
elsewhere
Environment variables are the pragmatic baseline — good enough for most applications, and a real improvement over files. Their weaknesses are worth knowing: they’re visible to the whole process, often to child processes, and frequently dumped into crash reports.
Anything in the browser is public
The rule that gets violated most often, usually by accident:
NEXT_PUBLIC_* bundled into the client
VITE_* bundled into the client
window.config readable
a "secret" in a
data attribute readable
Minification is not obfuscation. Any key that reaches the browser is public, and the correct response is to design for it: publishable keys with restricted scope, server-side proxying for anything privileged, and origin restrictions on the key itself.
A “server-side” key placed in a tag manager container is in the browser. This is a real and common leak path on retail sites — Third-Party Scripts.
Preventing the commit
.gitignore .env, *.pem, credentials
← necessary, insufficient
pre-commit hooks gitleaks, git-secrets —
scan the diff before it
lands
CI scanning catch what got through
GitHub push
protection blocks known secret
patterns at push
.env.example committed, with EMPTY
values, so nobody has
to guess what's needed
Pre-commit scanning is the highest-value control here — it’s the only one that acts before the secret exists in history.
Rotation
A secret that has never been rotated is a secret nobody knows how to rotate.
DESIGN FOR IT
support two valid keys at once, so
rotation isn't a cutover
→ issue new → deploy → revoke old
ROTATE ON
a schedule
anyone with access leaving
any suspected exposure
a dependency compromise
Test rotation before you need it. Discovering mid-incident that a key is hard-coded in three services is the worst time to find out.
Least privilege
a key that can only READ products
a key scoped to ONE store
a key restricted to your server's IP
a key that expires
Scope every credential to the narrowest thing that works. It converts a leak from a breach into an inconvenience, and it’s usually a checkbox at issue time that nobody bothers with.
Practical checklist
- Rotate first, clean history second
- Never log request headers wholesale —
Authorizationends up in your log aggregator, which has different access controls than you assume - Redact in error reporting. Most tools support scrubbing rules; configure them
- Separate credentials per environment. A staging key with production access defeats the separation entirely
- Audit who can read the secret store, and treat that list as sensitive itself — Encryption Basics, Common Vulnerabilities