Return generic error pages to the client.
In the event of an unhandled exception, that is, one that propagates to the application boundary, return a generic error page to the user. To do this, configure the <customErrors> element as follows:
<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />
The error page should include a suitably generic error message, possibly with additional support details. The name of the page that generated the error is passed to the error page through the aspxerrorpath query parameter.
You can also use multiple error pages for different types of errors. For example:
<customErrors mode="On" defaultRedirect="GenericErrorPage.aspx">
<error statusCode="404" redirect="GenericErrorPage.aspx"/>
<error statusCode="500" redirect="GenericErrorPage.aspx"/>
</customErrors>
For individual pages you can supply an error page using the following page-level attribute:
<% @ Page ErrorPage="YourErrorPage" %>
Disabling Trace Information to the User.
//Trace information is also extremely useful to attackers. Check the <trace> element to ensure that tracing is disabled.
<trace enabled="false" localOnly="true" pageOutput="false" requestLimit="10" traceMode="SortByTime"/>
Implement page-level or application-level error handlers
If you need to trap and process unhandled exceptions at the page level, create a handler for the Page_Error event that is similar to the one shown below.
public void Page_Error(object sender,EventArgs e)
{
// Get the source exception details
Exception ex = Server.GetLastError();
// Write the details to the event log for diagnostics
. . .
// prevent the exception from propagating and generating an
// application level event (Application.Error)
Server.ClearError();
}
If exceptions are allowed to propagate from the page handler or there is no page handler, an application error event is raised. To trap application-level events, implement Application_Error in Global.asax, as follows:
protected void Application_Error(Object sender, EventArgs e)
{
// Write to the event log.
}