An alternative title for this post would be: “Why you should never deploy your ASP.Net application with debug set to true to a production server”.
An easy way to expose your ASP.Net website to hackers is to publish it to a production site with the debug attribute in the “compilation” element set to true. The reason for this is that exception messages are typically more verbose. Hackers try and make your website throw an exception, because they can then use the verbose exception messages to determine names of database tables and fields as well as property names in your application’s classes. In addition, deploying an application with debug set to true results in:
- The compilation of ASP.NET pages takes longer (as batch compilation is turned off)
- Code typically executes slower
- Memory footprint is increased
- Scripts and images downloaded from the WebResources.axd handler are not cached
- Requests do not time out (this is bad, as in a production environment we dont want requests to be stuck indefinitely)
The obvious fix is to remember to set debug=false whenever you publish your website to a production environment. But what if you forget to set debug=false? This was something that always worried me…
And today I found out about the deployment element…
What makes the deployment element special is that it is a machine level configuration element. When its retail attribute is set to true, it will disable the <compilation debug=”true”> for ALL ASP.Net applications running on that machine. In addition, it turns of detailed errors messages being sent to remote machines and disables the ability to trace output.
Here is how you set it (remember this is not an application level, web.config element, and is set only in the machine.config file, typically found in “%windir%\microsoft.net\Framework\[VersionNumber]\CONFIG”)
<configuration> <system.web> <deployment retail="true"/> </system.web> </configuration>