OWASP Top 10 Web App Testing

What is the OWASP Top 10?

The Open Web Application Security Project (OWASP) Top 10 is a project that was created to provide web application designers an awareness of some standards that developers and web application security engineers should adopt to reduce their risk. The items that are listed are developed by security experts around the world, and they are determined by a broad consensus of the most common threats.


The OWASP Top 10 standards should be adopted and implemented by companies with a web presence to provide protection against common threats and to reduce their overall risks. Many companies are mandated to abide by specific compliances to maintain specific certifications. While the OWASP Top 10 is not a requirement for compliance, it is a standard that is used as a baseline security threshold for companies to follow.


Web application attacks are the leading cause of cybersecurity breaches to businesses every year. As of 2019, these attacks have increased by over 900% since 2014. The average web application has around 30 vulnerabilities with 6 of them being a high severity level. Vulnerable web applications result in coding errors that can allow attackers to gain access to web applications with the potential of stealing sensitive information or doing damage to a company's system.

There are multiple areas of concern with vulnerable web applications. As of 2017 the most observed web application attacks, 55% of them, have been from the SQL injection (SQLi) variety. The methods used in SQLi attacks are able to be prevented, however, these methods can be overlooked during the build process of the website. If these issues are identified quickly it will allow the businesses to take control and resolve the issues quickly. The use of SQLi has been around for many years and it is now well-understood with how the attack vector is implemented and there are several mitigation strategies to help reduce the overall risk that a system will be breached.

The OWASP Top 10 is a regularly-updated report that outlines the security concerns that impact web application security. This project focuses on the 10 most critical risks, and periodically changes the topmost risks. The report is put together by teams of security experts from around the world. This document is a guideline for issues to be aware of and actions to take to help strengthen the security of the web application.



Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Broken Authentication:

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

Sensitive Data Exposure:


Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sellers utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.

Data exposure risk can be minimized by encrypting all sensitive data as well as disabling the caching* of any sensitive information. Additionally, web application developers should take care to ensure that they are not unnecessarily storing any sensitive data.


Caching is the practice of temporarily storing data for re-use. For example, web browsers will often cache webpages so that if a user revisits those pages within a fixed time span, the browser does not have to fetch the pages from the web.


XML External Entities (XXE):


This is an attack against a web application that parses XML* input. This input can reference an external entity, attempting to exploit a vulnerability in the parser. An ‘external entity’ in this context refers to a storage unit, such as a hard drive. An XML parser can be duped into sending data to an unauthorized external entity, which can pass sensitive data directly to an attacker.

The best ways to prevent XEE attacks are to have web applications accept a less complex type of data, such as JSON**, or at the very least to patch XML parsers and disable the use of external entities in an XML application.

The XML or Extensible Markup Language is a markup language intended to be both human-readable and machine-readable. Due to its complexity and security vulnerabilities, it is now being phased out of use in many web applications.

JavaScript Object Notation (JSON) is a type of simple, human-readable notation often used to transmit data over the internet. Although it was originally created for JavaScript, JSON is language-agnostic and can be interpreted by many different programming languages.




Broken Access Control:


Access control refers to a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example, a web application could allow a user to change which account they are logged in as simply by changing part of a URL, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls on them. Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is whom they say they are, without having to constantly enter their login credentials.

Security Misconfiguration

Security misconfiguration is the most common vulnerability on the list and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user's overly-descriptive errors which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

Examples include:

If Directory listing is not disabled on the server and if the attacker discovers the same then the attacker can simply list directories to find any file and execute it. It is also possible to get the actual code base which contains all your custom code and then to find serious flaws in the application.

App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws. Attackers grab that extra information that the error messages provide which is enough for them to penetrate.

App servers usually come with sample apps that are not well secured. If not removed from the production server would result in compromising your server.

Cross-Site Scripting

Cross-site scripting (XSS) is an exploit where the attacker attaches code onto a legitimate website that will execute when the victim loads the website. That malicious code can be inserted in several ways. Most popularly, it is either added to the end of a url or posted directly onto a page that displays user-generated content. In more technical terms, cross-site scripting is a client-side code injection attack.

Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a url path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser. For example, an attacker could send an email to a victim that appears to be from a trusted bank, with a link to that bank’s website. This link could have some malicious JavaScript code tagged onto the end of the url. If the bank’s site is not properly protected against cross-site scripting, then that malicious code will be run in the victim’s web browser when they click on the link.

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content. Using modern web development frameworks like ReactJS and Ruby on Rails also provides some built-in cross-site scripting protection.

Insecure Deserialization

This threat targets the many web applications which frequently serialize and deserialize data. Serialization means taking objects from the application code and converting them into a format that can be used for another purpose, such as storing the data to disk or streaming it. Deserialization is just the opposite: converting serialized data back into objects the application can use. Serialization is sort of like packing furniture away into boxes before a move, and deserialization is like unpacking the boxes and assembling the furniture after the move. An insecure deserialization attack is like having the movers tamper with the contents of the boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources, and can result in serious consequences like DDoS attacks and remote code execution attacks. While steps can be taken to try and catch attackers, such as monitoring deserialization and implementing type checks, the only sure way to protect against insecure deserialization attacks is to prohibit the deserialization of data from untrusted sources.

Using Components with Known Vulnerabilities:

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls on them. Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is whom they say they are, without having to constantly enter their login credentials.

Insufficient Logging & Monitoring:

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.