Common Development Mistakes

Now a days, development environments are “smart” enough to catch and fix many mistakes that early developers battled with regularly. There are even many different development platforms that easily turn simple static HTML pages into highly interactive applications. The purpose of this blog post is to shed light on some of the common mistakes made in different stages of the web development process. I have touched on a few general topics that are common to virtually all web developers.

#1: Incomplete input validation

Validating user input on client and server side is simply a must do! We are all aware of the sage advice“do not trust user input” but, nevertheless, mistakes stemming from validation happen all too often.

One of the most common consequences of this mistake is SQL Injection.

Most front-end development frameworks provide out-of-the-box validation rules that are incredibly simple to use. Additionally, most major back-end development platforms use simple annotations to assure that submitted data are adhering to expected rules. Implementing validation might be time consuming, but it should be part of your standard coding practice and never set aside.

#2: Authentication without proper Authorization

Before we proceed, let’s make sure we are aligned on these two terms.

Authentication: Verifying that a person is (or at least appears to be) a specific user, since he/she has correctly provided their security credentials (password, answers to security questions, fingerprint scan, etc.).

Authorization: Confirming that a particular user has access to a specific resource or is granted permission to perform a particular action.

Stated another way, authentication is knowing who an entity is, while authorization is knowing what a given entity can do.

Let me demonstrate this issue with an example:

Consider that your browser holds currently logged user information in an object similar to the following:

{

    username:'elvis',
    role:'singer',
    token:'123456789'

}

When doing a password change, your application makes the POST:

POST /changepassword/:username/:newpassword

In your/changepasswordmethod, you verify that user is logged and token has not expired. Then you find the user profile based on the :usernameparameter, and you change your user’s password.

So, you validated that your user is properly logged-in, and then you executed his request thus changing his password. Process seems OK, right? Unfortunately, the answer is NO!

At this point it is important to verify that the user executing the action and the user whose password is changed are the same. Any information stored on the browser can be tampered with, and any advanced user could easily updateusername:'elvis'tousername:'Administrator'without using anything else but built-in browser tools.

So in this case, we just took care ofAuthenticationmaking sure that the user provided security credentials. We can even add validation that/changepasswordmethod can only be executed byAuthenticatedusers. However, this is still not enough to protect your users from malicious attempts.

You need to make sure that you verify actual requester and content of request within your/changepasswordmethod and implement properAuthorizationof the request making sure that user can change only her data.

AuthenticationandAuthorizationare two sides of the same coin. Never treat them separately.

#3: Not optimising bandwidth usage

Most development and testing takes place in a local network environment. So when you are downloading 5 background images each being 3 MB or more, you might not identify an issue with 1 Gbit connection speed in your development environment. But when your users start loading a 15 MB home page over 3G connections on their smartphones, you should prepare yourself for a list of complaint sand problems.

Optimising your bandwidth usage could give you a great performance boost, and to gain this boost you probably only need a couple of tricks. There are few things that many good web developers do by default, including:

1. Magnification of all JavaScript
2. Magnification of all CSS
3. Server side HTTP compression
4. Optimisation of image size and resolution