# Oops: I Leaked Secrets — GitGuardian warned me ...

I thought I was safe.

My .gitignore had all the usual rules:

.env
.env.*
*.env

But one day, I discovered that my .env.dev and .env.prod files were exposed in a side project.

Here’s what I learned and what you should do if this ever happens to you.

---

1. .gitignore Doesn’t Undo History

Adding files to .gitignore only prevents future commits.

If a file was previously committed, Git will continue tracking it. That’s why changes to my .env.prod were still showing up.

👉 Lesson: .gitignore is not retroactive.

---

2. Immediate Response Matters

The moment you suspect a leak, act fast.

• Revoke exposed keys — treat them as compromised
• Rotate API keys, database passwords, tokens
• Redeploy applications with fresh secrets
• Audit logs for suspicious activity

👉 Assume the worst. Delay increases risk.

---

3. Cleaning Your Repository History

Deleting the file is not enough.

Sensitive data may still exist in past commits.

To fully remove it:

• Use tools like BFG Repo-Cleaner or git filter-repo
• Rewrite commit history
• Force push the cleaned repository

👉 This is the only way to truly scrub secrets.

---

4. Preventing Future Leaks

A few practices that help:

• Double-check .gitignore paths

• Avoid storing critical secrets in .env files

• Use secret managers:

  • AWS Secrets Manager
  • HashiCorp Vault
  • GitHub Secrets

• Educate your team: once committed, secrets persist unless explicitly removed

---

5. Stop Tracking Immediately

If a file is already tracked:

(after banging head multiple times)

git rm --cached .env 

This removes it from Git tracking without deleting it locally.

---

Key Takeaway

.gitignore is not a safety net — it’s a guardrail.

If secrets leak:

Rotate → Clean → Monitor

Security isn’t about never making mistakes.
It’s about responding correctly when they happen.

---

If you’ve faced something similar, I’d love to hear how you handled it.