A secret in git isn't deleted, it's rotated (and why)
The scene is universal: you accidentally push a .env with an API key, notice five minutes later, run git rm, a "remove secret" commit, and breathe out. Wrong move: the secret is still there, intact, in the history. And by now, someone else probably has it too.
Why deleting it doesn't delete it
Git doesn't store "the current state", it stores every change. Your deletion commit adds a new line to the history, it doesn't rewrite it. The secret is still reachable with a trivial command:
git log -p | grep -i "api_key"
git show <commit-where-you-added-it>And it's not just your clone. If you pushed it to a shared repo, assume you no longer control it: there are forks, colleagues' clones, provider-cache copies, CI logs and backups. Worse: automated bots scan public commits in real time; a leaked AWS key can be mining crypto in your account within minutes.
First thing, always: rotate
The instinct is "I'll delete the commit and it's fixed". No. The very first thing is to revoke and rotate the credential at the provider (AWS, GitHub, Stripe, your database…). From the second a secret touches a repo, treat it as compromised —even if the repo is private—. Rotating is what cuts the risk; everything else is cleanup.
Scrubbing history: useful, but not the cure
Once the credential is rotated, you can rewrite history to remove the trace with git filter-repo (or BFG). But understand its limits:
- It rewrites the hashes of every later commit → breaks anyone with clones and forces a force-push.
- It does not delete clones, forks or caches that already exist.
- It's hygiene, not containment. Skip the rotation and the secret stays valid whether or not it's in history.
Where they hide (beyond history)
- Git history: the classic, "deleted" for show.
- Committed
.env: almost always an incomplete.gitignoreor a recklessgit add .. - CI/build logs: a debug
echo $TOKENthat ends up in a public log. - Hardcoded in the code: "temporary" keys nobody removed.
commit, run your diff, your .env or your config through the Secret Scanner: it detects AWS keys, GitHub/Slack tokens, private keys, JWTs and high-entropy strings, in your browser (nothing is uploaded). The cheapest way to catch the secret is to never let it reach the repo. And if the leak is a JWT, see also why a token reads without a key.Prevention that actually works
- ✅
.envalways in.gitignore; share a valueless.env.example. - ✅ Pre-commit hooks (gitleaks, trufflehog) that block the commit if they spot a secret.
- ✅ Secret scanning + push protection from the provider (GitHub, GitLab) to stop the push.
- ✅ Secrets in a manager (Vault, AWS Secrets Manager, runner env vars), never in the file tree.
- ✅ And the golden rule: rotate by default. When unsure whether a secret leaked, rotate it; it's cheaper than investigating.
Checklist for a leak
- ✅ Rotate/revoke now (this first, always).
- ✅ Review the key's usage since it leaked (provider logs).
- ✅ Optional: rewrite history (
git filter-repo/BFG) after rotating. - ✅ Close the door:
.gitignore, pre-commit hook, push protection. - ✅ Scan before committing next time.
"I already deleted it" is the sentence that precedes the AWS bill. In git, a secret isn't deleted: it's rotated. Internalize that difference and you'll dodge the incident that starts with "but I removed it in the next commit".
Cybersecurity Analyst · SOC · Sentinel/KQL specialist