Securing Connection Strings and AppSettings in ASP.NET Core

ASP.NET Core applications rely on configuration files appsettings.json to store critical settings such as connection strings, API keys, and third-party service credentials. If left unprotected, these values can expose sensitive data to attackers, especially if the repository is public or a breach occurs.

In this article, we'll explore strategies to secure connection strings and app settings in ASP.NET Core applications.

Why Securing AppSettings Matters

Connection strings may include database usernames and passwords.
API keys & secrets can grant access to external services (payment providers, email gateways, cloud APIs).
Misconfigurations can expose secrets in logs or error messages.

If these values are compromised, attackers can steal or manipulate data, escalate privileges, or abuse external services.

Default ASP.NET Core Configuration

By default, ASP.NET Core loads configuration from multiple sources:

appsettings.json
appsettings.{Environment}.json
Environment variables
User secrets (for development)
Key vaults/secrets managers (production)

This layered model makes it easier to separate development and production secrets.

Option 1: Use User Secrets (Development Only)

The Secret Manager tool helps store sensitive data locally without committing it to source control.

Setup

dotnet user-secrets init
dotnet user-secrets set "ConnectionStrings:DefaultConnection" "Server=.;Database=AppDb;User Id=sa;Password=StrongPass123;"

Access in Code

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

Best for local development.
Not suitable for production deployments.

Option 2: Use Environment Variables

Environment variables are safer than plain JSON files and align with 12-factor app principles.

Example: Set Environment Variable

Windows (PowerShell)

$env:ConnectionStrings__DefaultConnection="Server=.;Database=AppDb;User Id=sa;Password=StrongPass123;"

Linux/macOS (Bash)

export ConnectionStrings__DefaultConnection="Server=.;Database=AppDb;User Id=sa;Password=StrongPass123;"

ASP.NET Core automatically maps environment variables (using : replaced by __).

Works across cloud hosting (Azure, AWS, Docker, Kubernetes).
Requires secure OS-level management of environment variables.

Option 3: Use Azure Key Vault or AWS Secrets Manager

For production-grade apps, offload secrets to a cloud vault.

Azure Key Vault Integration

using Azure.Identity;

builder.Configuration.AddAzureKeyVault(
    new Uri($"https://{builder.Configuration["KeyVaultName"]}.vault.azure.net/"),
    new DefaultAzureCredential());

AWS Secrets Manager Integration

using Amazon.SecretsManager;
using Amazon.SecretsManager.Model;

var secretsManager = app.Services.GetRequiredService<IAmazonSecretsManager>();
var secret = await secretsManager.GetSecretValueAsync(new GetSecretValueRequest
{
    SecretId = "MyApp-DbConnection"
});

Secrets never appear in files.

Supports key rotation and auditing.

Option 4: Encrypt Sensitive Sections in Configuration

If you must store secrets in files, encrypt them at rest.

Example using ASP.NET Core Data Protection API

using Microsoft.AspNetCore.DataProtection;

public class SecureConfigService
{
    private readonly IDataProtector _protector;

    public SecureConfigService(IDataProtectionProvider provider)
    {
        _protector = provider.CreateProtector("AppSettings.Encryption");
    }

    public string Protect(string plainText) => _protector.Protect(plainText);
    public string Unprotect(string cipherText) => _protector.Unprotect(cipherText);
}

You could encrypt values before writing them appsettings.json and decrypt them at runtime.

Protects secrets if config files are leaked.

Still requires careful key management.

Option 5: Connection String Encryption at Database Level

Some databases support Transparent Data Encryption (TDE) or Always Encrypted (SQL Server).

Always Encrypted (SQL Server): Encrypts data at the column level and requires client-side driver integration.
TDE: Protects database files at rest.

These complement—but don't replace—application-level secret management.

Best Practices

Never commit secrets to source control.
Use User Secrets in dev and Key Vaults/Secrets Manager in production.
Prefer environment variables over JSON files.
Enable role-based access to secrets (Managed Identity in Azure, IAM in AWS).
Rotate secrets and keys regularly.
Audit and log secret access.

Conclusion

Securing connection strings and app settings is a critical step in building safe and compliant ASP.NET Core applications.
For development, use User Secrets. For production, rely on environment variables or better yet, Azure Key Vault or AWS Secrets Manager. Combine these with encryption and database-level security for maximum protection.

By following these practices, you reduce the risk of exposing sensitive data and strengthen your application's security posture.