I’ve been blogging for Windows Azure stuff for the past 3 years. Nonetheless, I’m still catching up .NET and its family pretty closely.

We’ve been listening to the best practices so far from anywhere (such as MSDN, conferences, blogs, etc.). But whether to follow the best practices or not could be another side of the story. Today, I’m gonna blog something special (at least to me). Not best practices, but bad practices. Aha! This serves as the warnings to you when developing ASP.NET application, things that you shouldn’t do in ASP.NET.

I’ve been gathered quite a few bad practices from various sources including personal experiences, feedback from colleagues, online articles and blogs, presentations, MSDN, and so many more. I’ll be discussing 5 of them first in this post will catch up more in upcoming posts.

Disclaimers!

Don’t get me wrong when you see the title. I’m not saying to use ASP.NET is a bad practice. Not even saying that ASP.NET is bad. To me, ASP.NET is awesome web development platform and I really love it. In fact, some of the web vulnerabilities or shortages has been answered and covered by ASP.NET by default.

Unfortunately, sometimes there’re always misuses, overuses, abuses, or deprecated features that we should really paying attention to. Coz they really can be timed-bomb in your house and make your days worst.

Most of them within the discussion here are ASP.NET related. However, you might see some of them are pretty generic web programming mistakes / bad practices, which also applicable in ASP.NET.

Additionally, you will also find some that are generic in .NET which applicable in others .NET app, not only applicable in ASP.NET. But I believe they’re significant enough to be in the discussion.

Alright, now let’s go for them now!

ASP.NET Bad Practices

 

1. Not Validating User Input

This is very fundamental yet frequently-made mistake. The impact might be pretty serious if it’s combined with others bad practices (discussed subsequently)

DO NOT

• Forget to validating user input
• Think all users are bad guys!
• Especially Textboxes and FileUploaders

WHY

• Potential of SQL Injection victim
• Potential of Cross Site Scripting victim

DO

• Validate! Validate! Validate!
• max length
• type (int, string, etc.)
• special character (with Regex)
• Double Protection
• Client Side + Server Side
• ASP.NET Validation Controls

 

2. Connection to database with inline SQL

DO NOT

• Executing database command with inline SQL query and concatenated string

 

string cmd = string.Format("SELECT ProductId, ProductName, QuantityPerUnit, UnitPrice FROM PRODUCTS WHERE ProductName like ‘%{0}%’", searchText);

WHY

• Potential of SQL Injection victim

DO

• Cmd.Parameters.Add()
• This is slightly better

 

sqlCmd.Parameters.Add(new SqlParameter("@ProductName", txtProductName.Text));

PREFERRED

• Stored Procedure
• ORM (Entity Framework / NHibernate / etc.)

 

3. User accounts privilege on database access

DO NOT

• Give more than sufficient permission database access

WHY

• Unauthorized access
• If it’s SQL Injected, you will be like this:

http://images.colourbox.com/thumb_COLOURBOX3461207.jpg

DO

• Find out what permission the app really needs
• Give only what they need
• Execute Store Proc only
• Execute Table only

 

4. Paging in data controls

TRY TO AVOID

• Using Default Paging on ASP.NET data controls
• It’s actually depending on your data source

WHY

• It’s bringing entire data in the table while just showing a fraction of it
• Unnecessary round trip from web server to DB Server

UNLESS

• When data is relatively small
• Assess your trade-off
• Dev effort VS performance

PREFER

• Using custom server side paging
• Using effective data source:
• ADO.NET EF Data Source
• TIPS: Use SQL Profiler to see the generated T-SQL when performing paging

 

5. Storing big objects in viewstate and sessions

TRY TO AVOID

• Storing big / plenty objects in ViewStates and Sessions

WHY

• Performance
• Big size page, due to viewstate, like this:

• Memory leakage on web / app server

DO

• Know really what you need
• Store only what you use
• Disposing them away when no longer in used

 

Okay, that’s all for the part 1. Check out again the part 2 soon.