CWE-11 is an ASP.NET misconfiguration with a plain cause. The application is set up to produce debug binaries, and those binaries end up in production. MITRE's summary is that debugging messages help attackers learn about the system and plan an attack.
Debug binaries are meant for development and testing. They give detailed debugging messages, and MITRE says they should not be used in production environments.
How it happens
ASP.NET lets a team switch an application into debug mode through configuration. It is a normal part of development, because the extra detail speeds up bug hunting. The risk is in how the setting travels. A configuration file is copied between environments, a release is built in the wrong mode, or a hotfix is pushed in a hurry with the debug flag still on.
Nothing fails when this happens. The site runs, perhaps a little slower, and starts emitting more information than it should.
What an attacker gains
MITRE lists one consequence: read application data. Attackers can use the additional information in debugging output to mount attacks aimed at the framework, the database or other resources the application depends on.
That is reconnaissance handed over for free. The more precisely an attacker knows what is running, the less they need to guess.
How to find it
The record names automated static analysis as one detection method. Static application security testing can inspect source and compiled code for this kind of setting without running the app.
You can also check by hand:
- Open the configuration shipped with each environment and look for the debug compilation setting.
- Compare production configuration against a known good baseline.
- Request a page that triggers an error in a test copy of production and see how detailed the output is.
How to fix it
Turn the setting off for anything that is not a developer machine:
<system.web>
<compilation debug="false" />
</system.web>
Then make that the default, not a memory test:
- Build releases in release mode only.
- Use configuration transforms so each environment gets its own values.
- Add a pipeline check that fails the build if the debug flag is true in a production configuration.
- Keep debug settings out of files that are shared across environments.
Try it yourself
Run a scan of your own code and see how static analysis reports configuration problems alongside code flaws.
Click through it at your own pace, or open it full screen.
Quick check
Does debug mode break the site?
No, and that is the danger. The application keeps working, so nobody notices the extra information leaving.
