Bits of .NET

⚙️ Committed appsettings.json = Exposed Secrets

A connection string or API key hardcoded into appsettings.json and committed to Git isn’t just visible to your team — if the repo is ever made public, forked, or breached, that secret is exposed permanently, and simply deleting it in a later commit does NOT remove it from history.

🐞 The Problem

{
  "ConnectionStrings": {
    "Default": "Server=prod-db;User Id=admin;Password=RealPassword123;"
  }
}
// Committed once, this password now lives in every clone of the
// repo forever, in every commit after it too, even if you
// "remove" it in the next commit.

✅ The Right Setup Going Forward

• Local development: dotnet user-secrets, stored outside the repo in your user profile, never committed.
• Production: environment variables or a real secrets manager (Azure Key Vault, AWS Secrets Manager) — never a checked-in file.
• appsettings.json should only ever contain non-sensitive defaults and placeholders.

🔐 Local Dev With User Secrets

dotnet user-secrets init
dotnet user-secrets set "ConnectionStrings:Default" "Server=...;Password=...;"
# Automatically picked up by IConfiguration in Development -
# stored in your user profile, never touches the repo at all.

🚨 If a Secret Is ALREADY Committed

• Rotate/change the actual secret FIRST — this is the only step that matters immediately; rewriting history doesn’t un-expose a password that’s already been seen.
• Removing it in a new commit is not enough — the old commit still has it, and anyone with any clone still has it.
• Rewriting history (git filter-repo, or GitHub’s own secret-scanning remediation guide) only helps for FUTURE clones; assume every existing clone and any CI cache already has the old value.