/ whiteweb.security _
whiteweb.security / guides / web.config exposed
web.config High severity ~7 min read

My web.config got exposed. What should I do?

IIS's web.config is the master configuration file for ASP.NET applications. It often contains database connection strings with embedded passwords, API keys in appSettings, and — in older apps — unprotected machineKey elements used for encryption. An exposed web.config needs immediate credential rotation.

A leaked machineKey is especially dangerous — rotate it and recycle the app pool.

IIS normally prevents web.config from being served as static content. If it's reachable, something has gone wrong with your server configuration — possibly a reverse proxy misconfiguration or a path traversal that bypasses IIS handling. Fix the root cause, not just the symptom.

// the 60-second version

  • Identify how web.config became reachable and block the route at the reverse proxy or web server.
  • Rotate database passwords, API keys, and regenerate the machineKey if one was present.
  • Encrypt the connectionStrings and appSettings sections using IIS configuration encryption.
  • Review IIS access logs for requests to the file during the exposure window.

01Understand what web.config can contain

A web.config is an XML configuration file that IIS reads to configure an ASP.NET application. Sensitive data that commonly appears in it includes:

  • <connectionStrings> — ADO.NET connection strings with embedded SQL Server usernames and passwords, often for multiple databases (primary, reporting, session state).
  • <appSettings> — key-value pairs for application configuration. Developers frequently store API keys, OAuth client secrets, and SMTP credentials here.
  • <machineKey> — the validationKey and decryptionKey used for signing and encrypting ViewState, FormsAuth tickets, and session state. With these keys, an attacker can forge ViewState to achieve remote code execution on classic ASP.NET WebForms applications.
  • Custom config sections — many frameworks and libraries add their own config sections that may include credentials.

An exposed machineKey in a WebForms application enables remote code execution. Known exploits (e.g., the ysoserial.net ViewState gadgets) allow an attacker to craft a malicious ViewState payload that is accepted as valid, triggering arbitrary command execution on the server. Treat this as an active compromise scenario.

02Block access and investigate the root cause

IIS is designed to refuse requests for web.config — it's a protected file type in the default IIS configuration. If it's accessible, something has overridden this. Common causes include:

  • A reverse proxy (Nginx, HAProxy, Caddy) sitting in front of IIS that serves static files directly and doesn't forward web.config requests to IIS's handler.
  • A static file server or CDN serving the directory without exclusions.
  • An incorrectly configured virtual directory or path that bypasses IIS module processing.
nginx — block web.config when reverse-proxying IIS/etc/nginx/sites-enabled/…
location ~* web\.config$ {
    deny all;
    return 404;
}

03Rotate all exposed credentials

Open the exposed web.config and work through every credential systematically:

  1. SQL Server connection strings — change the SQL login password in SQL Server Management Studio, then update the connection string.
  2. appSettings API keys — revoke each key in the relevant provider's dashboard and generate replacements.
  3. machineKey — generate a new key pair. You can use this PowerShell one-liner to generate cryptographically random hex strings:
generate a new machineKeyPowerShell
(1..64 | ForEach-Object { '{0:X2}' -f (Get-Random -Max 256) }) -join '' # run twice — once for validationKey (64 bytes) and once for decryptionKey (32 bytes)

After updating the machineKey, all existing FormsAuth cookies and ViewState will become invalid — users will be logged out. That's the correct response to a key compromise.

04Encrypt sensitive configuration sections

ASP.NET supports encrypting individual web.config sections using the Data Protection API (DPAPI) or RSA. This means even if the file is read, the values are unreadable without the server's encryption key:

encrypt connectionStrings using aspnet_regiiscmd (run as Administrator)
REM encrypt the connectionStrings section aspnet_regiis.exe -pe "connectionStrings" -app "/MyApp" REM verify encryption (section should now show EncryptedData) aspnet_regiis.exe -pd "connectionStrings" -app "/MyApp"

DPAPI encryption is machine-specific — the encrypted section can only be decrypted on the server where it was encrypted. For web farms, use RSA-based encryption with an exportable key container instead.

05Review IIS logs and move secrets to environment variables

Search IIS logs for requests to the file. IIS logs are typically in C:\inetpub\logs\LogFiles\:

search IIS logs for web.config requestsPowerShell
Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC1\*.log" ` -Pattern "web\.config" | Where-Object { $_ -match " 200 " }

Long-term, migrate production secrets out of web.config entirely. ASP.NET Core supports reading secrets from environment variables, which take precedence over appsettings.json. For classic ASP.NET, use environment variables or Azure App Service application settings, which override web.config values at runtime without requiring them to be present in the file at all.

If the exposed web.config contained a machineKey, consider your ASP.NET application potentially compromised — not just misconfigured. Review your application event logs and IIS access logs for unusual requests around and after the exposure window.

Was this guide useful?

These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.

More guides Buy me a coffee ☕

// related guides

appsettings.json
My appsettings.json got exposed. What should I do?
 .env
My .env file got exposed. What should I do?