How can developers protect sensitive configuration and connection information in an ASP.NET Core application?

Sensitive configuration is one of the areas where a small development shortcut can become a major security problem.

Connection strings, API keys, passwords, certificates, tokens, and other credentials should not be treated as ordinary application configuration.

A common anti-pattern is:

{
  "ConnectionStrings": {
    "DefaultConnection": "Server=...;User Id=admin;Password=..."
  }
}

Even when this works technically, committing such credentials to source control creates unnecessary exposure.

Understand configuration by environment

ASP.NET Core supports different configuration sources, and developers should understand the configuration hierarchy rather than putting everything into one file.

For local development, developers can use mechanisms such as:

User Secrets

For example:

dotnet user-secrets set "ConnectionStrings:DefaultConnection" "..."

This keeps development secrets outside the normal project configuration files.

However, User Secrets are primarily intended for development and should not be treated as a production secret-management solution.

Production: use a secret-management service

For Azure-hosted applications, Azure Key Vault is commonly used to centralize sensitive information.

The architecture can become:

ASP.NET Core Application
        ↓
Managed Identity
        ↓
Azure Key Vault
        ↓
Secrets / Certificates / Keys

The application does not need to embed a password directly in source code.

Managed identity is particularly important

Rather than storing a credential for the application to authenticate to Key Vault, Azure-hosted applications can use a managed identity.

Conceptually:

Application
    ↓
Managed Identity
    ↓
Azure authentication
    ↓
Key Vault

This reduces the need to distribute long-lived credentials.

Separate configuration from secrets

Not every configuration value is a secret.

For example:

Environment = Production
Region = East US
FeatureFlag = true

doesn't necessarily require secret storage.

But:

Database password
API key
Client secret
Private certificate
Signing key

should receive much stronger protection.

This distinction helps prevent both overengineering and accidental secret exposure.

Never rely only on .gitignore

A common beginner mistake is:

"I added appsettings.Production.json to .gitignore, so the secret is safe."

That isn't a complete security strategy.

Developers also need to consider:

• CI/CD logs
• Build artifacts
• Container images
• Application logs
• Exception messages
• Local developer machines
• Source-control history
• Infrastructure configuration
• Monitoring systems

A secret accidentally committed to Git may remain in repository history even after the current file is removed.

Connection strings aren't always enough

Modern applications may use:

• Managed identities
• OAuth tokens
• Workload identity
• Key Vault
• Azure App Configuration
• Service-specific authentication mechanisms

The right mechanism depends on the service and deployment architecture.

Practical architecture

A production Azure application might use:

Developer
   ↓
Source Control
   ↓
CI/CD
   ↓
Azure App Service / Container Apps
   ↓
Managed Identity
   ↓
Key Vault

The application receives configuration securely without embedding permanent credentials into the application code.

What students should practice

Build an ASP.NET Core API that:

1. Uses normal configuration for non-sensitive values.
2. Uses User Secrets locally.
3. Uses managed identity in Azure.
4. Reads a secret from Key Vault.
5. Ensures secrets aren't written to logs.
6. Deploys through a CI/CD pipeline.

That project teaches application development + Azure security + deployment architecture together.