Fix guide · high · exposed_web_config

ASP.NET web.config exposed

Why it matters

ASP.NET / IIS configures itself via Web.config files. IIS normally refuses to serve them — but reverse proxies, Nginx fronts, Kubernetes pods using nginx-ingress, or misconfigured handlers can end up serving the file as-is.

What's typically inside:

• <connectionStrings> — database connection strings, often with the password in plaintext: <add name="Db" connectionString="Server=...;Database=...;User Id=sa;Password=P@ssw0rd123" />.
• <appSettings> — arbitrary key-value config. Often used for API keys, SMTP credentials, third-party tokens.
• <machineKey> — the cryptographic key used to sign ASP.NET cookies and ViewState. With this key, an attacker forges valid sessions and can sometimes achieve RCE via ViewState deserialization (notorious in older ASP.NET WebForms apps).
• <system.web> debug attributes — debug="true" exposes more error detail than production should.

Every one of these is a real, actionable disclosure. This is one of the worst single files to leak.

How to fix it

1. Block .config paths at the web server. For IIS, this should already be the default — the <staticContent> handler refuses *.config. Confirm it's not overridden:

``xml <system.webServer> <security> <requestFiltering> <hiddenSegments> <add segment="web.config" /> </hiddenSegments> </requestFiltering> </security> </system.webServer> ` For nginx as a reverse proxy: location ~* \.config$ { return 404; }`.

1. Rotate every credential in the file. Treat all of them as compromised.
2. Move secrets out of web.config. Use ASP.NET Core's user-secrets / Azure Key Vault / AWS Secrets Manager — anything that keeps credentials out of source-controlled config files.
3. Disable debug mode in production. <compilation debug="false"> and remove any customErrors mode="Off" blocks.

Did vibecheck flag this on your app?

If you reached this page from a vibecheck inspection report, the redacted match in your scan output is the exact string we found in your bundle. After applying the fix above, run the inspection again — the finding should clear.