Protecting web.config Secrets in a Legacy ASP.NET Application

Editorial illustration.

Originally published 23 June 2023; rewritten and reviewed on 15 October 2026.

A connection string in web.config can be essential to an older ASP.NET application and uncomfortable to leave readable. Encrypting the section can reduce exposure, but the application still needs a usable key. I would plan key ownership and recovery before changing the file.

Keep the framework boundary clear

The original article concerned .NET Framework protected configuration, not ASP.NET Core’s configuration system. For an existing application, confirm the supported provider and deployment model. A Windows machine-bound arrangement and a web farm with multiple servers need different key handling.

A legacy API pattern is:

var configuration = WebConfigurationManager.OpenWebConfiguration("~");
var section = configuration.GetSection("connectionStrings");
if (!section.SectionInformation.IsProtected)
{
    section.SectionInformation.ProtectSection(
        "RsaProtectedConfigurationProvider");
    section.SectionInformation.ForceSave = true;
    configuration.Save();
}

This requires the appropriate .NET Framework configuration namespaces, permissions and provider setup. It is a deployment operation to validate in a controlled environment, not code to expose through a public web endpoint.

Protect the key as carefully as the file

Limit which identity can use the key and verify that the application pool has the required access. Back up the configuration and follow a documented key backup or export procedure suitable for the provider. Encrypting a section without a recovery plan can turn a server replacement into an outage.

Encryption at rest does not protect a secret from code already running with the application’s authority. Keep source repositories and diagnostic logs free of credentials, and use the deployment platform’s supported secret facilities when modernising.

Test a cold start and a restore

Restart the application under its intended identity and exercise the database connection. Rehearse restoring onto the target environment before relying on the change. The successful outcome is a protected configuration that the right service can use and the team can recover.

Related reading