Secrets Management
A database password sitting in `appsettings.json` is a plaintext string your next `git commit` ships to everyone with repo access. The same value, read the same way, can instead live somewhere version control never sees.
- ▸Securing a secret changes where its bytes live, not how you read it:
Configuration["Db:Password"]works the same from any source. - ▸Nothing gets encrypted: the plaintext file just moves out of the repo, and loads only in
Development,nullelsewhere. - ▸A managed store is one more provider, so last-writer-wins still decides the value and a config dump still leaks it.
A connection string in appsettings.json carries its password in plain text:
// appsettings.json
{ "Db": { "Password": "hunter2", "Host": "db.internal" } }Read it back and the value arrives as an ordinary string:
var pwd = builder.Configuration["Db:Password"]; // "hunter2"
Nothing here is special. Db:Password is a key in the same flat store every provider writes into, resolved by the same provider order, and builder.Configuration[...] is the same read you would use for a log level or a base URL. The password's problem is not how it is read, it is where it lives: appsettings.json is tracked by source control.
git status # modified: appsettings.json
The moment you commit, that password ships to everyone with repo access, and it stays in the history even after you delete it. Every technique in this topic keeps builder.Configuration["Db:Password"] exactly as it is and changes only the provider that answers it, so the secret stops being a string in a committed file.