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

enableviewstatemac

DO

  • Always set it to TRUE

viewstate_mac

 

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

request_validate

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:

 

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

This entry was posted in ASP.NET, Bad Practices and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

*