ASP.NET Don'ts and Dos

Introduction

Some folks may keep falling into a trap and are unaware of what they are doing. This post highlights the Dos and the Don’ts in general regarding ASP.NET. The majority of the items listed are taken from the ASP.NET team recommendations. Though this may not be a complete checklist, it covers some of the most common “gotchas” folks run into.

If you know other tips about the Dos and Don’ts in ASP.NET in general, feel free to drop a comment so I can update the list. :)

Control Adapters

If some of you are still using Control Adapters, especially those WebForms folks - you should avoid it, as much as possible.

• Avoid: Control Adapters, as these were created to support mobile controls rendering different markups for different devices.

• Prefer: CSS media queries, responsive design and mobile specific views.

Style Properties on Controls

• Try to Avoid: The four thousand specific control style properties, e.g. EditItemTemplate-AlternateItem-Font-ForeColor-SomeStyle-Blah-Blah :S
• Using inline CSS styles, e.g. style=“color:yellow;text-align:center;”
• Prefer: CSS stylesheets. You can roll your own or use Bootstrap or a combination of your own CSS.

JavaScript Frameworks and AjaxControlToolkit

• Try to Avoid: Mixing your jQuery code, or other JS frameworks code with WebForm's AjaxControlToolkit controls to avoid functionality issues.
• Prefer: Stick to the specific control libraries.

UpdatePanel Control

• Do Not: Over use it (Think about performance and maintainability)
• Do: Use it, when necessary and if it makes sense to use it.
• Try to Avoid: It doesn’t help you to become a better web developer.
• Prefer: AJAX e.g jQuery AJAX can be used to do asynchronous updates.

Page and Control Callbacks

• Try to Avoid: Page callbacks or control callbacks.
• Prefer: Anything else, e.g. Page Method, Web Service, AJAX, Web API.

Scripts and CSS Files

• Do: Minify, bundle your CSS and Script files when deployed on production.
• Try to Avoid: Deploying unminified scripts and CSS when you can minify them.

Static Script References

• Try to Avoid: Referencing local script references (e.g jQuery)
• Prefer: Use CDN (Content Delivery Network), when referencing is done on static files
• But Always: Do a fallback local reference, in case CDN fails

Capability Detection

• Try to Avoid: BrowserCaps, as it has a history of breaking as new browser versions are released
• Prefer: Client-side feature detection and lightup, such as via Modernizr.

SQL Queries

• Do Not: Append input values directly into your SQL statement because it can lead you to SQL Injection attacks. It’s a big NO NO!

• Do:

  (1) Use parameter queries
  (2) Stored Procedures
  (3) ORM e.g. Entity Framework, NHibernate etc.
  

This article highlights the prevention of SQL Injection. Protect Your Data: Prevent SQL Injection

Displaying of Data

• Do Not: Display huge amounts of data in your page as it can affect the performance of your App, and it is not user-friendly.

• Do: Limit the amount of data to be displayed.

  (1) Filter out items and load the associated data.
  (2) Apply paging (e.g using custom paging with LINQ or using SQL paging).
  (3) Apply data caching (but be careful: use it only where it makes sense).

Request Validation

• Do Not: Depend on the request validation to protect your site against XSS attacks.

• Do:

  (1) Validate well-formedness of the data 
           "Is this user-submitted value, a valid System.Uri whose scheme is http: or https:?"
  (2) Encode data on the way out.
           CSHTML: @foo ? ASPX: <%: foo %>
  (3) Don’t forget about JavaScriptStringEncode, UrlEncode, etc.

Cookieless Forms Auth& Session

• Do Not: Enable cookieless forms authentication or session, as they could make your users victim to malicious attacks.

• Do:

  (1) Enable "require cookies" for these features.
  (2) Consider using only secure (SSL) cookies for the sites serving sensitive information.
  

EnableViewStateMac

For the developers who use ASP.NET runtime < 4.5.2

• Do Not: Set EnableViewStateMac = false

• Not Ever: Not even on a single page.

  "But I’m not using ViewState!" is not a valid excuse.
  

• Do: Tease Microsoft for even allowing this as an option in the first place. :D

  Well MS already forbids it when they released ASP.NET 4.5.2.
  

Medium Trust

• Do Not: Depend on Medium Trust (or any other <trust> level) as a security boundary.

• Do:

  (1) Place untrusted Applications into their own Application pools.
  (2) Run each Application pool under its own unique identity.
  (3) You can follow some guidance here: https://support.microsoft.com/en-us/kb/2698981.

appSettings

• Do Not: Use <appSettings> to disable Microsoft security fixes for any lengthy time in production.
• Do: Use Microsoft security-sensitive <appSettings>config as temporary compatibility that shims while rolling out Server upgrades or patches.

Consult the list here.

UrlPathEncode

• Do Not: Use UrlPathEncode to encode the arbitrary user-provided strings.

• Do:

  (1) Sanitize inputs instead, checking submitted URL for well-formation.
  (2) Use UrlEncode to encode the user input meant to appear as a query string parameter in the URL.

PreSendRequestHeaders & PreSendRequestContent

• Try to Avoid: Registering for these events from within managed IHttpModule instances.
• Prefer: Using native IIS modules, if you need to hook these asynchronous pipeline events.

Asynchronous Page Events

• Try to Avoid: Writing async void methods [like Page_Load] for page life-cycle events.
• Prefer: Using Page.RegisterAsyncTask() instead, if you need to register asynchronous work.
• Do: Set <httpruntimetargetframework=“4.5”> if using Task.

Response.Redirect & End

Be Aware: Reponse.Redirect(String) calls Response.End(), which aborts the current thread in synchronous requests and halts the code execution.

For asynchronous handlers, Response.End() does not abort the current thread, so code execution continues.

If you need to redirect the response, use the method appropriate for the framework you’re using. For example, in MVC, return a RedirectResult instead of calling Response.Redirect.

EnableViewState & ViewStateMode

• Try to Avoid: Using EnableViewState.

• Prefer:

  (1) Set ViewStateMode="Disabled" at page directive level.
  (2) Set ViewStateMode="Enabled" only on the controls that require state.

SQLMembershipProvider

Be Aware: Replaced by the UniversalProviders and ASP.NET identity which works with all the databases and the Entity Framework supports including SQL, Azure SQL, SQL Compact, MySQL and more.

Long-Running Request

• Try to Avoid: Session, as ASP.NET will forcibly release the session object lock at a potentially inopportune time Blocking I/O operations.
• Prefer: WebSockets, if possible, has much lower per-request memory overhead.

Real-Time Updates

• Try to Avoid: The traditional way of pinging the Server for the updates with AJAX.
• Prefer: ASP.NET SignalR. It provides a simple and clean API that allows you to create real-time web apps. HTML5 is also worth trying.

WebForms

• Do Not: Stick to use Web Forms.

• Do

  (1) Learn other technologies that ASP.NET offers such as MVC, Web API, SignalR and ASP.NET Mobile. 
      Also check out the new ASP.NET Core.
  (2) Learn JavaScript frameworks (e.g Angular, Knockout, React etc..).
  (3) Keep up to date with what’s the latest and know the new features it offers.

Reference

• What Not to Do in ASP.NET

CodeProject