Jit- announcement icon

Announcing our bidirectional integration with Wiz to level-up contextual prioritization!

Learn more

The 2024 In-Depth Guide to OWASP Top 10 Vulnerabilities & How to Prevent Them

For app security, start from the beginning: the OWASP Top 10 list is an indispensable resource that saves time, effort, and money.

Shlomi Kushchi writer profile image
By Shlomi Kushchi
Jit Logo
Edited by Jit Team

Updated December 3, 2024.

the 2021 in - depth guide to owaps top 10 vulnabities

The OWASP Top 10 list is the go-to resource to begin understand application security risk for software developers and information security professionals.

Most of us don't know we're harboring vulnerabilities in plain sight. During 2020 and 2021, there were an average of 15 vulnerabilities per site, and two out of these fifteen vulnerabilities were of high severity.

‍To protect against vulnerabilities, you first need to be aware of them. That’s where the OWASP Top 10 list comes in handy. Despite having launched close to 20 years ago, this list has been constantly maintained and refreshed to reflect current vulnerabilities.

OWASP Top 10 Vulnerabilities Overview

1. Broken Access Control

2. Cryptographic Failures

3. Injections

4. Insecure Design

5. Security Misconfigurations

6. Vulnerable and Outdated Components

7. Identification and Authentication Failures

8. Software and Data Integrity Failures

9. Security Logging and Monitoring Failures

10. Server-Side Request Forgery (SSRF)



What is OWASP?

The Open Web Application Security Project (OWASP) is a non-profit organization aiming to improve software security.

In 2021, OWASP celebrated 20 years of excellent work.

Driven by community contributors and maintainers, OWASP produces widely adopted open-source tools & resources. One of the most popular is its long-standing list of the top ten most critical web application security risks, updated annually. 

Some of the tools and technologies that OWASP has created to help developers secure their applications include the OWASP Dependency Check for finding vulnerabilities within a project’s dependencies and the OWASP ZAP Proxy, which tests web applications for vulnerabilities. 

» Unfamiliar with ZAP? Discover how to use OWASP ZAP for pen testing.

A pie chart showing OWASP Top 10 threats


What is OWASP Top 10?

The OWASP Top 10 is published every four years and is based on data from the previous four years. The list is not structured around how severe each vulnerability is. Instead, it compiles vulnerabilities based on how common they are so you can prevent the most common risks to sensitive data exposure.

OWASP Top Ten is a starting point for organizations to improve their software security.



OWASP Top Ten 2017 vs. 2021

Cyber vulnerabilities continuously change, and OWASP Top 10 list adapts to reflect that. Since the last list was released in 2017, quite a lot has been modified.

Three new categories were added:

  • Insecure Design
  • Software and Data Integrity Failures
  • Server-Side Request Forgery (SSRF)

Some of the vulnerabilities published on OWASP Top 10 2017 have also changed name or scope to adapt to market changes:

Insufficient Logging and Monitoring is now called Security Logging and Monitoring Failures.

Some vulnerabilities have remained unaltered, but they have moved spots:

Broken Access Control is now considered the most common vulnerability, taking the number one spot.

Below we will look at the latest OWASP Top Ten list and each vulnerability in detail.

Comparison between OWASP Top 10 lists for 2017 and 2021


Breaking down the OWASP Top 10 Vulnerabilities

As the world of web application security continues to evolve, the OWASP Top 10 threats provides a robust framework for developers and security professionals to identify and mitigate the most common attacks.

Here are the OWASP Top 10 vulnerabilities and tips on how to prevent them.

1. Broken Access Control

In a nutshell, broken access control means that an attacker can access resources or data they should not have access to. This can be done in many ways, but typically by exploiting flaws in how the system controls access to those resources. 61% of all breaches involve broken access control.

There are many ways to exploit broken access control, but the result is always the same: the attacker gains access to data or resources they should not have access to.

Preventing Broken Access Control

Access control is a security measure that protects resources from unauthorized access. There are many different ways to achieve this, but one common method is to use a whitelist.

A whitelist is a list of authorized users that are allowed to access a particular resource.

This list can be maintained manually or generated automatically based on user credentials.

A whitelist can be implemented by creating a list of approved websites or IP addresses and then comparing any incoming requests against that list. If the request is not on the list, it will be blocked.

One way to create a whitelist on AWS is through an IAM policy that allows access only to the specific IP addresses or CIDR ranges that you wish to allow access to, and configuring your security groups to only allow traffic from those IP addresses or CIDR ranges.

2. Cryptographic Failures

Insecure communications constitute a significant problem on the internet today.

Unencrypted or weakly encrypted communications can be intercepted and read by anyone with the right tools. This can lead to the disclosure of sensitive information, like passwords, financial data, and personal information.

In 2023 alone, there were well over 8 billion records breached, and the average cost of a data breach sits at around $4.54 million.

Preventing Cryptographic Failures

When data is sent over the internet using HTTPS, it is encrypted using a cryptographic algorithm, which makes it difficult for attackers to read or tamper with the data.

To implement HTTPS in Nginx, you will need to purchase and install an SSL certificate. Once you have your certificate, you will need to edit your Nginx configuration file to enable SSL.

The specific directives you need to edit will depend on your configuration, but they will typically be something like:

ssl_certificate /path/to/your/certificate.crt;

ssl_certificate_key /path/to/your/certificate.key;

After you have edited your configuration file, you will need to restart Nginx for the changes to take effect.

3. Injections

Injections are one of the most common web application vulnerabilities. They occur when user input is not properly sanitized before being used in an SQL query or other operation.

This allows attackers to execute their SQL code, potentially resulting in data loss or corruption. In some cases, it may also allow attackers to access sensitive information such as passwords or credit card numbers.

There are many different types of SQL injection attacks, but they all exploit the same basic vulnerability.

A graph showing the steps of an SQL injection


Preventing Injections

Cross-site scripting (XSS) attacks occur when a malicious user injects code into a web page that is then executed by other users who visit the page. This can lead to the theft of sensitive information or the execution of unwanted code on the user's machine.

Sanitizing user input is important because it helps to prevent XSS attacks.

There are a few ways to sanitize user input in React, Vue, and Angular:

  • In React: Use the DOMPurify library to sanitize user input. DOMPurify will parse and sanitize HTML, making it safe to render on your page.
  • In Vue: Use the v-html directive to render HTML safely. The v-html directive will ensure that any HTML code passed to it is properly encoded and escaped, making it safe to render.
  • In Angular: Use the DomSanitizer service to sanitize user input. DomSanitizer will help you prevent XSS attacks by sanitizing untrusted values that are passed into your application.

» Examine these malicious code examples so you can recognize them easily

4. Insecure Design

Insecure design refers to security flaws introduced during software development's design phase. Design flaws can lead to a wide range of security vulnerabilities, including:

  • Injection flaws: User input is not properly sanitized before it's used by the application. The malicious code is injected and then executed by the application, leading to data loss or corruption, Denial of Service (DoS) attacks, or arbitrary code execution.
  • Cross-site scripting (XSS) flaws: XSS flaws occur when user input is not correctly escaped or sanitized before it's displayed by the application. Attackers inject malicious code executed by unsuspecting users who visit the compromised page.
  • ‍Broken authentication and session management: These occur when authentication and session management mechanisms are not correctly implemented. Attackers can access sensitive data, hijack user sessions, or perform other malicious actions.
  • Insecure communications: Insecure communications refer to the use of insecure protocols or encryption algorithms that allow attackers to eavesdrop on communications or tamper with data.

Preventing Insecure Design

One way to prevent cross-site scripting is to implement a content security policy (CSP).

A CSP is a list of directives that specify what resources are allowed to be loaded on a page.

These directives can be used to restrict the sources of content that can be loaded on a page and can be implemented in the <meta> tag of an HTML document or in the HTTP headers of a server.

Here is an example of a content security policy implemented in the <meta> tag of an HTML document:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://example.com;">

This policy allows content from the same origin (self) to be loaded by default and will allow images from https://example.com to be loaded.

Here is an example of a content security policy implemented in the HTTP headers of a server:

Content-Security-Policy: default-src 'self'; img-src https://example.com;

This policy will have the same effect as the policy above.



5. Security Misconfigurations

Security misconfiguration is a broad category of issues that can arise when an application or server is not configured correctly.

Incorrectly configured systems are more vulnerable to attacks, allow unauthorized access to sensitive data, and provide misleading information to users.

All too often, systems are not adequately configured because administrators don't have the time or knowledge to do so correctly, which leaves systems open to attack. Sometimes, administrators are aware of how important proper configuration is, but corporate policies and other restrictions may prevent them from ensuring it.

Common security misconfiguration issues include:

  • Leaving the default administrator account active and using weak passwords
  • Not disabling directory listing
  • Not requiring SSL/TLS for sensitive communications
  • Not properly restricting access to files and directories
  • Not properly securing database passwords and other sensitive data
An illustration with security misconfiguration examples


Preventing Security Misconfigurations

One way to make SSL/TLS compulsory is to use a web server that requires it for all connections. For example, the Apache web server can be configured to require SSL/TLS by adding the following directive to the server configuration:

SSLRequireSSL

Another way to make SSL/TLS compulsory is to use a load balancer or proxy server that supports SSL/TLS and requires it for all connections.

For example, the Nginx web server can be configured as a proxy server to require SSL/TLS by adding the following directive to the server configuration:

proxy_ssl_session_reuse on;

proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

proxy_ssl_ciphers HIGH:!aNULL:!MD5;

6. Vulnerable and Outdated Components

Vulnerable and outdated components are often the Achilles' heel of an organization's security posture. A vulnerable component is one with known security flaws that can be exploited to gain unauthorized access or cause other harm.

An outdated component is one for which security patches or updates are no longer available from the vendor, making it more susceptible to attack.

Preventing Vulnerable and Outdated Components

Preventing vulnerable and outdated components is not complicated—which is all the more reason to do it.

The best ways to prevent vulnerable and outdated components include:

  • Removing all unused components
  • Monitoring components for vulnerabilities
  • Limiting access to components
  • Regularly auditing components

» Learn how to automate OWASP ZAP for easier monitoring.

7. Identification and Authentication Failures

An identification and authentication failure occurs when a system fails to correctly identify and/or authenticate a user.

This can happen for various reasons, but typically it is due to:

  • Weak or easy-to-guess passwords
  • Lack of strong password policies
  • Lack of two-factor authentication.

Organizations are vulnerable to approximately $1.76 million in business costs when a Zero Trust authentication system is not implemented.

An example of identification and authentication failures


Preventing Identification and Authentication Failures

There are many ways to implement 2-factor authentication (2FA) with AWS. One way to do it is to use AWS Identity and Access Management (IAM) with multi-factor authentication (MFA). 

IAM is a web service that helps you securely control access to AWS resources.

MFA adds an extra layer of security by requiring a second factor, such as a code from a hardware device or a mobile app, in addition to your username and password.

To set up an MFA, you first need to create an IAM user and then attach an MFA device to that user. You can use any type of MFA device that is compatible with AWS, such as a hardware device or virtual device.

Once you have an IAM user with an MFA device attached, you can enable MFA for that user. To do this, you need to create an IAM policy that requires MFA. You can then attach this policy to the IAM user. 

Here is an example of an IAM policy that requires MFA:

A script for identification and access management policy with multi-factor authentication


This policy denies all access to all resources unless the user has an MFA device attached.

After you have created this policy, you must attach it to the IAM user. You can do this via the AWS Management Console or the AWS Command Line Interface (CLI).

Once the policy is attached, the user must use MFA when accessing AWS resources.

8. Software and Data Integrity Failures

Data integrity failures are a type of security vulnerability that can occur when data is modified or destroyed without authorization. This can happen either through malicious attacks or accidental mistakes.

Software and data integrity failures can have serious consequences, such as financial losses or the exposure of confidential information.

There are several ways to protect data from integrity failures.

One is to use cryptographic methods, such as digital signatures or hashes, to verify that data has not been changed.

Another is to store data in multiple locations so that if one copy is destroyed, others can be used to reconstruct it. Back up data regularly so that a copy is always available in case of an integrity failure.

Preventing Software and Data Integrity Failures

In order to prevent software and data integrity failures, make sure to:

  • Regularly back up data and software
  • Keep software and data secure
  • Ensure data and software integrity
  • Monitor systems for changes
  • Detect and respond to changes quickly

9. Security Logging and Monitoring Failures

In the world of information security, logging and monitoring failures are all too common.

Log data integrity failures can lead to data loss or corruption while monitoring failures allow attackers to operate undetected.

Security logging is tracking events that occur on a computer or network. This data can be used to identify attacks, monitor system activity, and track user behavior. However, if this data is not secured correctly, attackers can compromise it.

Failures can have severe consequences for an organization. The average life cycle of a breach is 200 days, which, on average, translates to $4.45 million in costs.

An illustration of a Top 10 vulnerability for security logging and monitoring failure


Preventing Security Logging and Monitoring Failures

To prevent security logging and monitoring failures, a company can:

  • Ensure that all logging and monitoring tools are correctly configured and tested
  • Establish clear and concise logging and monitoring policies and procedures
  • Educate all staff on the proper handling of sensitive information
  • Regularly review logs and monitor activity for unusual or suspicious activity
  • Investigate and resolve any issues identified through logging and monitoring

10. Server-Side Request Forgery (SSRF)

Server-side request forgery (SSRF) is an attack in which the attacker tricks a server into requesting on their behalf.

SSRF can be performed by specifying a malicious URL in a parameter or embedding an HTTP request in an XML document. If the server does not properly validate the request, it will send the request to the attacker-specified URL.

SSRF can be used to attack internal systems that are generally not accessible from the outside. For example, an attacker could use SSRF to access a server's internal network or read sensitive files on the server.

Preventing Server-Side Request Forgery (SSRF)

Preventing a server-side request forgery includes several steps:

  • Ensure that user input is validated and sanitized
  • Restrict user access to only the resources that they need
  • Implement a whitelist approach to input validation
  • Monitor server access logs for suspicious activity
  • Keep all server software up to date with the latest security patches

Protect Your Applications Against OWASP Top 10 Threats

Malicious users never rest, and neither should your security postures.

To guard against attacks exploiting OWASP Top 10 vulnerabilities, try using tools like OWASP ZAP to run dynamic scans against your applications to look for holes.

Or, to quickly implement ZAP alongside other application security tools like SAST, SCA, secrets detection, and others, consider Jit to protect your applications against OWASP Top 10 vulnerabilities while causing no friction to your software engineering team.

"The Jit platform complements ZAP in many ways, allowing developers to programmatically leverage ZAP across applications in a streamlined manner as part of their broader security plans."

- Simon Bennetts, founder of OWASP ZAP

Jit integrates with OWASP ZAP and other open-source security tools out of the box.