CWE-12 says an ASP.NET application must enable custom error pages. Without them, the framework's built-in responses go to the visitor, and attackers mine those responses for information.
MITRE notes that the default error pages give detailed information about the error that occurred and should not be used in production. Attackers can use the added detail to target the framework, the database or other resources the application relies on.
How it happens
Default error pages are a development convenience. They show what failed and where. The trouble starts when the production site inherits the same behavior, usually because custom errors were never configured, or were configured for local requests only and nobody checked how remote requests behave.
A single unhandled exception on a public page is enough to expose the output.
What an attacker gains
The consequence in the record is confidentiality: read application data. Detailed messages tell an attacker what technology is in use, how the code is structured and sometimes what the failing operation was. That narrows the search for a working attack.
How to find it
Cause an error on purpose in a staging copy that is configured like production. Request a missing page, then a page with a bad parameter. If the response names internals, custom errors are not working.
Also read the configuration for each environment and confirm that custom errors are on for remote users.
How to fix it
Enable custom errors and give the visitor a generic page:
<system.web>
<customErrors mode="On" defaultRedirect="~/Error.aspx" />
</system.web>
Then:
- Keep the error page short, with no exception text.
- Log exceptions on the server so developers still get the detail.
- Test the setting in the real hosting environment, since local testing can behave differently.
- Check again after upgrades, because a framework change can alter error handling.
Try it yourself
A dynamic scan is a good way to see what your running site reveals when it breaks. This demo shows how a web app scan surfaces that kind of exposure.
Click through it at your own pace, or open it full screen.
Quick check
Where should the detailed error go?
Into your server logs, readable only by your team. The visitor gets a plain message.
