Presenting detailed debugging messages through ASP.NET tracing is always advantageous for developers to understand the root reason of a development or a production bug.

However, the same is true for attackers. An attacker presented a detailed exception will abuse it for a huge range of vulnerabilities; all injection types of vulnerabilities, padding oracle, business logic problems, mass assignment etc.

ASP.NET has a configuration directive, trace, which displays troubleshoooting information (top n requests, server variables, etc.) about the current request and the page at the bottom of individual pages. When debugging a problem is not an option, such as in production, tracing might help pinpointing a pesky error.

Here’s an insecure Web.config tracing directive;

            
<configuration>
<system.web>
<trace enabled="true" requestLimit="40" localOnly="false" />
</system.web>
… 
                 
            

While it’s possible to disable/enable tracing for all the application through Web.config, however it’s also possible to enable/disable trace for individual pages and this page directive takes precedence over attributes set in Web.config;

                
<%@ Page Trace="true" %>
                
            

While page tracing is possible for ASP.NET WebForms application it is also possible to print out tracing information in ASP.NET MVC applications, too, with a few options. One of them is shown below using Web.config configuration file;

                
<system.codedom>
<compilers>
<compiler language="c#;cs;csharp" extension=".cs" type="..."
compilerOptions="/define:TRACE" warningLevel="1" />
</compilers>
...