Professional ASP.NET MVC 3

Proper Error Reporting and the Stack Trace

Quite often sites go into production with the <customErrors mode=“off”> attribute set in the web.config. This isn't specific to ASP.NET MVC, but it's worth bringing up in the security chapter because it happens all too often.

There are three possible settings for the customErrors mode.

• On is the safest for production servers, because it always hides error messages.
• RemoteOnly shows generic errors to most users, but exposes the full error messages to users with server access.
• The most vulnerable setting is Off, which exposes detailed error messages to anyone who visits your website.

Detailed error messages can expose information about how your application works. Hackers can exploit this by forcing your site to fail—perhaps sending in bad information to a controller using a malformed URL or tweaking the query string to send in a string when an integer is required.

It's tempting to temporarily turn off the Custom Errors feature when troubleshooting a problem on your production server, but if you leave Custom Errors disabled (mode=“Off”) and an exception occurs, the ASP.NET run time shows a detailed error message, which also shows the source code where the error happened. If someone was so inclined, they could steal a lot of your source and find (potentially) vulnerabilities that they could exploit in order to steal data or shut your application down.

The root cause of this problem is waiting for an emergency to think about error handling, ...