ASP.NET Bad Practices: What you shouldn’t do in ASP.NET (Part 3)

Hello everyone! Hope the first and second articles are useful to you. This is third article of ASP.NET Bad Practices: What you shouldn’t do in ASP.NET. The next five bad practices are equally important as those discussed earlier.

Some of them are related to web.config. They are as following:

11. Turning “off” Custom Error in Production

DO NOT

• Set Custom Error to OFF in Production

WHY

• Source code, stack trace, others info will be exposed
• Version of ASP.NET, Servers, etc. exposed

DO

• Of course, set it ON or RemoteOnly
• Consider using “friendly” custom error page

12. Setting EnableViewStateMac=false in production

DO NOT

• Set EnableViewStateMac = false
• Do not set it to false even though you’re not using viewstate

WHY

• Opens up doors to a malicious user to tamper with the data in the viewstate
• This is pretty serious as MSDN also emphasize this obviously

DO

• Always set it to TRUE

13. Turning Off Request validation

TRY TO AVOID

• Turning off the RequestValidation
• RequestValidation will help to warn developer that there’s potential XSS (Cross Site Scripting) occur when it’s turned off.
• Here’s the screenshot of the warning

UNLESS

• You know what you’re doing
• Make sure that everything are properly HTML-encoded

WHY

• It creates opportunity for Cross Site Scripting

DO

• It’s actually on by default.
• Use a rich editor with built-in-HTML-encoded feature

14. Too Much “inline” javascript / css

TRY TO AVOID

• Writing too much inline javascript / css on the ASPX / HTML pages

WHY

• Lack of caching
• Code maintenance

PREFER

• Have it on the different files
• The files will be cached on browsers
• *Make use of CDN (Content Delivery Network) to improve performance further

15. Impersonation: do you really need to do so?

TRY TO AVOID

• Overuses / improper usage of impersonation
• Especially, impersonate to “admin” user

WHY

• Posing security risk
• Prevents the efficient use of connection pooling
• When accessing downstream databases
• Performance degradation

DO

• Clarify:
• Do you really need to impersonate?
• If you do, remember these:
• Consider using programmatic instead of declarative impersonation
• When impersonating programmatically, be sure to revert to the original context
• Alternatives approaches are depending on scenarios

Some References On This Point:

• http://www.hanselman.com/blog/AvoidUsingImpersonationInASPNET.aspx
• http://msdn.microsoft.com/en-us/library/ff649265.aspx#ImpersonationDelegation1

I’ll continue to updating the post again in future, making this series of posts an awesome ones. Stay tuned.