5 May 2021

The OWASP Top 10 Vulnerabilities & How To Prevent Them


With the continual demand and growth for web and mobile based services, the application development sector is one of the hottest and fastest growing around.

Often security is overlooked in favour of rich and powerful functionality. However, the consequences of a data breach can be devastating for an organisation of any size, highlighting the importance of security in software development. If you haven’t already checked out our recently blog on the Secure Software Development Lifecycle, you can do so here.

Do you want to know more about how you can create a secure development environment? Or are you looking for a provider to develop a web or mobile application and want confidence that they will operate with a strict security methodology and a highly competitive price? Then get in touch today at for a completely bespoke proposal to your requirements!


The Open Web Application Security Project (OWASP) is a non-profit global community, with the primary objective of promoting application security across the web. As such all of their knowledge base is freely and easily accessible on their website.


OWASP publishes a set of the top 10 web application vulnerabilities, based off the threat and potential impact of each.

There are four main criteria used to compile the OWASP top ten vulnerabilities;

  1. Exploitability
  2. Prevalence
  3. Detectability
  4. Business Impact

The list also includes a set of remediations and preventative actions and is compiled from a variety of expert sources, such as security consultants, security vendors and security teams from a variety of organisations.


The current list of OWASP Top 10 web application vulnerabilities being used by application developers and security teams is;

  1. Injection
  2. Broken Authentication
  3. Sensitive Data Exposure
  4. XML External Entities (XXE)
  5. Broken Access Control
  6. Security Misconfigurations
  7. Cross Site Scripting
  8. Insecure Deserialisation
  9. Using Components With Known Vulnerabilities
  10. Insufficient Logging & Monitoring

Let’s now break down each of these vulnerabilities to understand the methodology, impact and remediation actions.



Injection vulnerabilities occur when a query or command is used to insert untrusted data into an interpreter, such as SQL, OS, NoSQL or LDAP injection.

This untrusted data tricks the interpreter into taking an action that it was not designed for, such as accessing data without proper authentication.


Injection attacks can be prevented using the following actions;

  • Isolating commands from data, to avoid exposure to attacks that replace data with commands for execution
  • Use parameterised queries which code SQL with parameters, rather than structuring commands from user input
  • Eliminate the interpreter from usage, by utilising a secure API channel
  • Implement server-side validation, and an intrusion detection system to detect client-side activity



User authentication and session management governs access to systems and services. With incorrect or weak mechanisms, attackers can compromise passwords, security keys or session tokens and permanently or temporarily gain access to these systems.

It can also compromise other assets that are connected to the same network, or share the same authentication credentials.


Broken authentication vulnerabilities should be mitigated by;

  • Implementing multi-factor authentication (MFA) in case credentials are exposed
  • Do not use default credentials, especially for admin privileges
  • Enforce a strong password policy across all users
  • Carefully monitor failed login attempts across all systems
  • Use a session manager that generates random, time limited session IDs for users
  • Never include session IDs in URL requests



Insecure data or insufficient protection of data in transit or at rest can allow attackers to view, steal or modify sensitive data. This could be credentials, credit card information or other Personal Identifiable Information (PII) data.

Exposed data can be used for identity theft, fraud and industrial espionage, and as such data protection is required for web applications that process financial transactions, healthcare records or PII data.


Data should be protected both in transit (in motion) and at rest (in storage). This can be done by;

  • Using Transport Layer Security (TLS) to encrypt communication traffic
  • Using Virtual Private Networks (VPNs) to access sensitive resources remotely
  • Disable caching for user responses that contain sensitive data
  • Implement data storage and archival processes to not store data longer than needed
  • Encrypt sensitive information that is stored with a suitable encryption algorithm




XML is a commonly used protocol for exchanging information across web applications. For web applications that parse XML input, a poorly configured parser can be tricked into sending sensitive data to an unauthorised external entity.

XXE attacks are used to gain access to sensitive information, disclose internal files, scan internal ports, execute code remotely and mount Denial of Service (DoS) attacks.


XXE attacks can be prevented by;

  • Avoiding the serialisation of sensitive data
  • Using less complex data formats than XML, such as JSON reducing the dependency on a parser
  • Keeping XML processors and libraries patched and updated
  • Ensuring that XML or XSL file upload capability validates XML, for example using XSD validation



Access to a web application should be restricted to only those users that are authorised to that section, and only capable of completing actions that they have been defined to.

Broken access control occurs when security best practices are not followed, and systems have unsuitable access permissions. This commonly occurs with Software as a Service (SaaS) solutions and Content Management Systems (CMS) like WordPress, which generate access permissions by default.


Broken access control can be mitigated by;

  • Implementing the principle of least privilege
  • Clearly defining Role Based Access Control (RBAC) for all internal users
  • Deleting accounts that are no longer needed or active to prevent Shadow IT
  • Fully auditing activity on systems for all user accounts



Gartner estimates that around 95% of cloud breaches are the result of human error. Within the OWASP Top 10 this vulnerability is the most common, as it is the easiest to come about – either through negligence or lack of knowledge, users can expose a company’s environments.

This can occur through accepting default or insecure settings, creating overly accessible resources, misconfigured HTTP headers and error messages that contain sensitive information.


How to avoid human error? Let the machines in.

  • Use templates to deploy development, test and production environments that meet organisation security policies through Continuous Integration / Continuous Deployment (CI/CD)
  • Use Infrastructure as Code (IaC) such as AWS CloudFormation or Terraform to reduce human input into resource creation
  • Deploy minimal platforms and remove unused or unneeded features and services
  • Continuously monitor resources, applications and servers for misconfigurations



XSS occurs when malicious client-side JavaScript or HTML scripts are injected into a web page, and then the application is used as an attack vector against users that navigate to it. It can be used to hijack user sessions and gain their access, deface websites or redirect a victim to a site under the attacker’s control.


XSS vulnerabilities can be mitigated by;

  • Training developers in best practices, such as sufficient HTML/JavaScript escaping/Encoding techniques
  • Implementing code vulnerability testing at the design and development phases
  • Take a zero-trust approach to user input data and separate active browser content from unvalidated data



Insecure Deserialisation allows attackers to conduct remote code execution, injection attacks, replay attacks or escalate privileges.

For example, cookies on a web browser that contain serialised information about the user. An attacker could deserialise the object, modify it and give themselves a role and then serialise it again.


Whilst the logical mitigation would be to not accept serialised objects from untrusted sources, there are other precautions including;

  • Implementing digital signatures to ensure the integrity of serialised objects
  • Initiate type constraints during deserialisation so that application code can detect unexpected classes
  • Run deserialisation code in restricted environments to prevent exposure to high privileges



Web applications often include open-source and third-party components such as libraries and frameworks to enhance their capability. But a component with a known vulnerability creates an avenue for an attacker into the application.

Whilst it is one of the least ranked vulnerabilities in terms of problem severity, it is the highest ranked vulnerability for the root cause of a data breach, given that an attacker can discover the issue with a scan, and then use a predefined attack vector.


This vulnerability can be mitigated using the following methods;

  • All components should be in a well documented repository and under configuration management
  • These components should be monitored continuously for disclosed vulnerabilities
  • Patch management process should be implemented as an automated workflow as much as possible to speed up the process



Whilst all of the vulnerabilities listed here are significant issues for an organisation, this might be the most important message to take home. If you aren’t comprehensively logging and monitoring all of your environments how will you actually figure out there is an issue?

Even with logging in place, attackers will look to disrupt and disguise their activity, in order to bypass detection, tamper with servers, corrupt databases, steal sensitive data or plant malicious code.


Whilst step 1 involves configuring monitoring on all active systems, in order to detect sophisticated attackers an organisation should;

  • Ingest all logs to a central source such as a Security Incident & Event Management (SIEM) system
  • Ensure that all logs are timestamped to follow an audit trail
  • Ensure all audits are read only to avoid tampering and immutable to prevent deletion


The OWASP Top 10 is a really powerful guide when setting up a web application security program – however this is not all of the potential attacks that occur and there are a number of other areas to be wary of.


When user credentials are leaked or exposed on a website, attackers will often dump them, either on a dark web forum or on the surface web, potential on a site like PasteBin.

This becomes a significant problem when people re-use passwords across multiple websites, and even more of an issue when they reuse them on corporate logins. As creatures of habit it is tempting to reuse a rememberable password, but this provides an attacker with a potential route in.

From a company perspective it is difficult to force users not to reuse a password on different systems, so the most effective methods here are to use a Threat Intelligence tool to scan for compromised credentials, and enforce the use of MFA.


An organisation can have robust and strict policies in place, however this all counts for nothing if a malicious user within the organisation can simply bypass all of these by providing an attacker with their credentials, or trying to take malicious actions themselves.

Detecting a malicious insider can be tricky, similarly to monitoring you need to have a comprehensive view and audit trail of audit activity to ensure that these actions will be detected.

Other enhancements can involve strict RBAC to ensure the principle of least privilege is adhered to, and a third party solution such as a Cloud Access Security Broker (CASB) that can define strict restrictions on applications, such as preventing users from taking screenshots, copying or uploading files away from defined resources.



Technical controls are often the most discussed in today’s age – how to secure technical devices. However, what about an old school attack – simply stealing the device?

All corporate devices should be encrypted by default such as using BitLocker, enforce strict password policies on users and contain remote wipe capabilities for administrators to remove sensitive data. Other capabilities can include location based access and time based access, both parts of a CASB solution.

This can prevent a login to a device or system, even with the correct password, if the device is logging in from a new location, or at an unusual time of day such as outside of work hours.


Phishing is a significant challenge for organisations – ultimately you rely on the awareness of staff not to click on suspicious links and attachments. These links and attachments likely contain malicious software such as malware or ransomware.

Implementing security awareness training is an essential part of raising staff’s focus and awareness on cyber security issues. However, there are additional methods that can be added on top of this in the event that staff are deceived by these emails.

The use of a CASB solution or endpoint detection and response capability can automatically quarantine emails containing attachments. For more information check out our previously blog on how to identify phishing emails.


This attack vector has gained even more prevalence during the COVID-19 Pandemic, with more and more staff working remotely, and some using the Remote Desktop Protocol (RDP) to access resources.

Attackers can utilise man-in-the-middle attacks, trying to intercept traffic between the user and the resource, potentially gaining access to session information, exposing credentials and sensitive information.

To secure RDP connections, an RDP gateway should be used, and RDP should never be allowed over the open internet. The use of a VPN, as well as complex passwords and MFA can help to keep these communications secured.


The OWASP Top 10 Web Application vulnerabilities provides an excellent starting point for organisations looking to build a secure development environment. However, it is important to be aware that there are also still some very prevalent issues that affect organisations that are not in the Top 10, some of which we have highlighted in this blog.

Ultimately, when it comes to security there is no white glove solution that fixes every environment for every company. Each organisation should build out their security strategy and prioritisation based off their individual assessments, and the advice of any third-parties brought in to assist.

Do you want to know more about how you can create a secure development environment? Or are you looking for a provider to develop a web or mobile application and want confidence that they will operate with a strict security methodology and a highly competitive price? Then get in touch today at for a completely bespoke proposal to your requirements!