Protect Connection Strings and Credentials with Environment Configuration and Secret Stores

Learning outcomes

1. The connection string is part configuration, part authority

A database connection string may contain a server address, database name, encryption settings, application name, pool options, user name, password, access token mode, or local file path. Some fields are operational configuration; others are credentials. Treating the whole string as ordinary text risks committing secrets to Git, printing them in logs, copying production passwords into tests, or leaking them through exception diagnostics.

2. Keep committed appsettings free of credentials

{  "ConnectionStrings": {    "ServiceHub": "Data Source=servicehub-lab.db"  },  "Database": {    "Provider": "Sqlite"  }}

The mandatory local SQLite path needs no password, which makes it ideal for course labs. For a server provider, commit only non-secret defaults or a configuration key name—never a production password, token, private key, or connection string containing one.

3. User Secrets: useful for development, intentionally not a vault

The .NET Secret Manager keeps development secrets outside the project tree so they are not normally checked into source control. Microsoft explicitly states that User Secrets values are not encrypted and the mechanism is for development only. The next snippet uses ASP.NET Core’s WebApplicationBuilder, which combines .NET configuration with dependency-injection registration; a console/worker host can consume the same configuration keys with the generic host/configuration packages.

dotnet user-secrets initdotnet user-secrets set "ConnectionStrings:ServiceHubSqlServer"   "Server=localhost,1433;Database=ServiceHub;User Id=servicehub_dev;Password=local-dev-only;Encrypt=True;TrustServerCertificate=True"

var builder = WebApplication.CreateBuilder(args);var connectionString = builder.Configuration    .GetConnectionString("ServiceHubSqlServer")    ?? throw new InvalidOperationException("Database connection is not configured.");builder.Services.AddDbContext<ServiceHubContext>(options =>    options.UseSqlServer(connectionString));

Do not call Console.WriteLine(connectionString) to “verify” configuration. Instead, log a safe provider/environment label or perform a health check that reports success/failure without returning credentials.

4. Environment variables can override configuration, but may still be visible

.NET configuration uses environment variables naturally, including the cross-platform double-underscore separator. This avoids embedding a secret in the app package, but Microsoft warns that environment variables are commonly stored as plain text and can be read if the host/process is compromised.

export ConnectionStrings__ServiceHub="${SERVICEHUB_DB_CONNECTION}"export Database__Provider="PostgreSql"

Treat the environment as a transport mechanism whose security depends on the orchestrator/host. Restrict who can inspect deployment configuration and prefer a managed secret service when the platform provides one.

5. Production secret stores and managed identity are deployment choices

A production secret store centralizes secret access, audit, rotation and access policy. Azure Key Vault is one example; other clouds and on-premises platforms have equivalents. Identity-based database authentication can sometimes remove the database password from application configuration entirely—for example, Azure SQL with Microsoft Entra/managed identity—but that is provider/platform-specific and not mandatory for this course.

6. Deliberate failure: “temporarily” commit the password and rely on deletion later

{  "ConnectionStrings": {    "ServiceHub": "Server=db.prod;Database=ServiceHub;User Id=app;Password=P@ssw0rd!"  }}

Deleting the line in a later commit does not erase repository history, forks, build logs, caches, screenshots, or copied artifacts. Treat an accidentally committed secret as compromised: revoke/rotate it, review access logs, then remove it from active configuration. History rewriting may reduce future exposure but does not make the old credential trustworthy again.

7. Rotation and pool behavior need an operational plan

Server-provider connection pools can keep physical connections alive after configuration changes. Rotating a credential therefore requires more than updating a secret store: deploy/reload safely, ensure new connections authenticate, and retire/clear old pooled connections according to the provider’s supported mechanism. Do not teach an arbitrary “restart everything” rule; test the chosen provider and hosting model.

1. create/enable new credential or identity grant2. update secret reference / identity policy3. canary opens new connection successfully4. deploy/recycle according to provider pool behavior5. revoke old credential6. confirm authentication failures did not spike7. audit that old credential is no longer accepted

8. Safe startup and support diagnostics

Startup logs should record which provider/configuration mode is active, not the secret. A sanitized connection descriptor may include a known environment name and database logical name only if your threat model permits it. For SQLite, even a file path can reveal usernames or tenant locations, so classify it before logging.

logger.LogInformation(    "Database configured. Provider={Provider}; Environment={Environment}",    providerName,    app.Environment.EnvironmentName);// Never:// logger.LogInformation("Database={ConnectionString}", connectionString);

9. Mandatory lab: move a credential out of source and prove it stays out

1. Keep the mandatory SQLite lab as the zero-secret baseline.
2. Create a test-only server-provider connection string using a local account, never production credentials.
3. Initialize .NET User Secrets and store the connection string there.
4. Load it through IConfiguration; run a connectivity/migration-status probe without printing the string.
5. Verify git diff/git grep over the exercise project contains no password/token.
6. Override the same configuration key via an environment variable and explain the host-visibility risk.
7. Write a rotation checklist for the chosen provider and remove the local test secret when finished.

10. Production judgment and bridge

Secrets management is lifecycle management: creation, delivery, use, logging discipline, rotation, revocation and audit. EF Core consumes a configured connection; it does not secure the credential store. Lesson 4 asks a more important question: once the application is connected, how much authority should that runtime identity actually have?

Authoritative references

• Safe storage of app secrets in ASP.NET Core (.NET 10) — User Secrets, environment variables and development-secret warnings
• ASP.NET Core configuration (.NET 10) — configuration providers and environment-variable behavior
• Azure Key Vault configuration provider — optional managed secret-store example
• Azure SQL Microsoft Entra authentication — optional identity-based SQL authentication path
• OWASP Secrets Management Cheat Sheet — secret lifecycle, rotation and access-control guidance
• Microsoft.Data.Sqlite connection strings — free local provider configuration reference