Secure Connection Strings & Secrets

Connection strings, passwords, API keys, and tokens must not be hardcoded or committed to source control.

Recommended approach

1. Keep non-sensitive settings in appsettings.json

{
  "ConnectionStrings": {
    "DefaultConnection": ""
  },
  "EmailSettings": {
    "SmtpServer": "smtp.example.com"
  }
}

Do not store passwords or API keys here:

{
  "ApiKey": "real-secret-key"
}

appsettings.json is commonly committed to Git.

2. Use User Secrets during development

No additional library is normally required for an ASP.NET Core Web project.

Initialize User Secrets:

dotnet user-secrets init

Store a connection string:

dotnet user-secrets set "ConnectionStrings:DefaultConnection" "Server=localhost;Database=PortfolioDb;User Id=sa;Password=secret;TrustServerCertificate=True"

Store an API key:

dotnet user-secrets set "ExternalApi:ApiKey" "secret-key"

Read the values normally:

string? connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

string? apiKey =
    builder.Configuration["ExternalApi:ApiKey"];

WebApplication.CreateBuilder() automatically loads User Secrets in the Development environment.

Important: User Secrets are kept outside the project, but they are not encrypted. They are intended only to prevent accidental source-control commits during development.

3. Use environment variables

Environment variables override values from JSON and User Secrets.

ConnectionStrings__DefaultConnection=Server=prod;Database=PortfolioDb;...
ExternalApi__ApiKey=production-secret

Double underscore __ represents configuration hierarchy:

ConnectionStrings__DefaultConnection

becomes:

ConnectionStrings:DefaultConnection

Environment variables are better than source files, but they may still be readable by administrators or a compromised process. For highly sensitive production secrets, use a dedicated secret store.

4. Use Azure Key Vault in production

Install the libraries:

dotnet add package Azure.Extensions.AspNetCore.Configuration.Secrets
dotnet add package Azure.Identity

Configure Key Vault:

using Azure.Identity;

var builder = WebApplication.CreateBuilder(args);

var keyVaultUri =
    builder.Configuration["KeyVaultUri"];

builder.Configuration.AddAzureKeyVault(
    new Uri(keyVaultUri!),
    new DefaultAzureCredential());

Key Vault secret name:

ConnectionStrings--DefaultConnection

The provider converts -- into ::

ConnectionStrings:DefaultConnection

The application can read it normally:

var connectionString =
    builder.Configuration.GetConnectionString("DefaultConnection");

Prefer DefaultAzureCredential with Managed Identity in Azure. This avoids storing Key Vault credentials inside the application.

5. Prefer passwordless database access

When using Azure SQL, prefer Managed Identity:

Server=tcp:myserver.database.windows.net;
Database=PortfolioDb;
Authentication=Active Directory Default;
Encrypt=True;

This avoids storing a database username and password.

Security best practices

• Never commit secrets to Git.
• Never hardcode secrets in source code.
• Do not store production secrets in User Secrets.
• Use separate secrets for Development, Testing and Production.
• Give applications only the permissions they require.
• Rotate secrets regularly.
• Do not write connection strings, tokens or passwords to logs.
• Restrict access to production configuration.
• Revoke and replace a secret immediately if it is exposed.
• Use managed identities and passwordless authentication where possible.

Interview answer

For development, I use .NET User Secrets so sensitive values stay outside the project. In production, I use a managed secret store such as Azure Key Vault and access it through Managed Identity. Environment variables can be used for deployment overrides, but they may be stored as plain text. Secrets are never hardcoded, committed to Git, or written to logs.

References: Microsoft—Safe storage of app secrets and Azure Key Vault configuration provider.