What Are the OWASP Top 10 Vulnerabilities (And How to Mitigate Them)?

In 2017, Equifax suffered a massive data breach due to an expired digital certificate, which falls under one of the OWASP top 10 vulnerabilities categories. The incident cost Equifax nearly $2 billion. Learn how securing your organization against the vulnerabilities outlined in the OWASP top 10 list can help you make your apps more secure

Did you know that WordPress vulnerabilities have increased steadily since 2014, reaching a staggering 28,391 identified vulnerabilities? And this is just the tip of the iceberg. In fact, the Common Vulnerabilities and Exposures (CVE) list has now more than 170,000 entries, and more than 19,000 have the highest risk score of 9.0–10.0. (The scale is from 1 to 10, with 10 being the worst.)

And even if research made by Veracode showed a slight decrease in the percentage of applications with flaws listed the OWASP top 10 list of web application vulnerabilities, the percentage remains well over 60%. With IBM estimating the average cost of data breaches at a whopping $4.24 million per incident, web application vulnerabilities are not something that organizations can afford to ignore.

So, what are you and your organization doing to protect your customers and business from these attacks? This article will take you through the 2021 OWASP top 10 vulnerabilities list. You’ll discover some real-life examples of the most dangerous vulnerabilities and learn how to mitigate them. Because knowledge always pays off. 

Open Web Application Security Project (OWASP): What Is It?

The Open Web Application Security Project (OWASP) is a non-profit foundation focused on web application security. It publishes free articles, tools, and information with the collaboration of its open programmer and developer community contributors. The OWASP top 10 vulnerabilities list is part of this information.

OWASP Top 10 Vulnerabilities: What Is This List All About?

First published in 2003 and updated every few years since then, the OWASP top 10 list is a collection of the 10 most critical web application vulnerabilities and possible mitigations to address them. It’s recommended and used as a reference by several books and industry organizations, including:

• MITRE.
• Payment Card Industry Data Security Standard (PCI DSS).
• Defense Information Systems Agency (DISA).
• Federal Trade Commission (FTC).

The OWASP vulnerabilities list is based on feedback from app security researchers, developers, and other experts worldwide. It’s a combination of both contributed data and results from a community survey. The list categories are ranked based on the following criteria:

• The occurrence frequency of the identified vulnerability.
• The extent of damage that an attack could create (i.e., severity).
• The potential impact (or cost) of an attack related to the vulnerability.

Why is it so important? The OWASP top 10 is a highly regarded resource that helps developers and web application security professionals alike stay abreast of trending security risks and minimize risks to their applications. Furthermore, integrating the OWASP top 10 into your organization’s software development life cycle shows your customers that you care about security.

So, what about you then? Do your web applications OWASP top 10 compliant? Keep on reading to find it out!

What Are the Latest OWASP Top 10 Vulnerabilities?

Let’s have a look at the latest OWASP top 10 vulnerabilities. We’ll  go down the list to explore what each of these weaknesses are and how you can mitigate these issues.

OWASP Top 10 — #1: Relying on Broken Access Controls

In 2021, broken access controls became the most common and risky vulnerability with more than 318,000 occurrences of 34 common weakness enumerations (CWEs). When access permissions are set up or enforced incorrectly, the user or a malicious third party can get unauthorized access to sensitive information.

Image caption: An example of what an unauthorized user can do in case of broken access control

Common Access Control-Related Vulnerabilities

• Least privilege violation. Access to privileged roles, functions, and capabilities should be limited by the principle of least privilege or denied by default. When this is not properly set up, it expands your attack surface and leaves your apps and systems vulnerable.
• Bypass access control checks. Access control should be implemented in code on a trusted server to reduce the chances of an attacker modifying browsing parameters (e.g., modification of a URL or of an HTML page) or API requests.
• Unauthorized access to other users’ accounts. Each user should have access only to his own account (enforced record ownership), rather than be able to access to any record to reduce the risks of account misuse or modification.
• Unrestricted API access to all users. Access to APIs should be restricted issuing API keys (unique codes) to trusted partners only. Letting all users have free access to an API without POST, PUT, and DELETE access controls in place is never a good idea.
• Metadata manipulation. JSON web tokens should be immediately invalidated after logout to avoid attacks abusing them. When metadata isn’t properly managed and controlled, your apps and systems will be vulnerable to access control tokens, cookies, and hidden fields tampering.
• Force browsing. Access to specific pages (e.g., administrator dashboards) should be restricted by role-based authentication mechanisms. If not implemented, unauthenticated users will be able to access to any page and so will the attackers.

Check out also the complete list of mapped CWEs.

Real Life Example: Facebook’s Access Control Issues Left It Vulnerable to Exploit

Facebook had a brief taste of what could happen when a broken access control vulnerability is discovered. An independent security researcher figured out that a malicious user could add himself as an administrator of any Facebook Business Page and deny access to the legitimate page manager or admin. Luckily for Facebook, nothing happened at the time and the issue was immediately fixed — but it could have been a disaster if it had been discovered (and exploited) by someone less scrupulous.

How Can You Prevent Broken Access Controls?

• Improve your access management procedures and mechanisms. Implement multifactor authentication (or passwordless authentication), monitor and record failed access attempts, reduce the life of stateless JSON web tokens, and deny public access by default.
• Manage your privileges. Employ and enforce the principle of least privilege. Remember: just because someone wants access doesn’t mean they should have it.
• Do some clean-up. Get rid of unused services and inactive user accounts, and scan your code for flaws and errors.
• Perform integration tests. Ensure that integration testing is included in your application development process. This will enable you to detect and address any error or security flaw early in the development lifecycle.
• Rate limit your API. Adding a rate limit to your controller access and APIs will help you minimize the damage in case of an automated attack tooling.

OWASP Top 10 — #2: Allowing Cryptographic Failures to Occur

Cryptographic failures is a newly renamed category — previously called sensitive data exposure in the previous incarnation of the report. Sounds pretty vague, right? This term entails that when personal data like passwords, usernames, or other sensitive information aren’t adequately protected, they can be leaked or stolen by unauthorized third parties. It also allows them to use that data for malicious purposes, such as accessing affected users’ other accounts that might use the same credentials or using personal data to commit identity theft.

Not only is this a security-related issue, but it’s also a big compliance-related problem and can deal a nasty blow to your organization’s reputation. 

Common Cryptographic Security Vulnerabilities

• Data stored or transmitted in cleartext. Clear text is clearly a no-go for storage and, even worse, for data transmission. It’s like serving an attacker your customers’ sensitive data on a silver plate.
• Old cryptographic algorithms or protocols. While collecting vintage items is a great hobby, relying on legacy protocols and cryptographic algorithms just won’t do in cybersecurity. There isn’t a place for it — relying on deprecated algorithms like SHA1 and MD5 is just too risky and makes your organization an easy target.
• No key management. Are you still using the default crypto keys? Or, heaven forbid, re-using old weak ones without any kind of key management process in place? It’s time to change.
• No encryption in place. Encryption is at the core of every secure app and website. Without it, stealing your sensitive data will be just as easy for an attacker as stealing candy from a baby.
• Incorrect server certificate validation. An attacker might be able to spoof your business’s digital identity, which enables them to interfere in the communication path between the legitimate server and client.

For more information, be sure to check out this complete list of mapped CWEs.

Real Life Example: Cloudflare’s Servers Shared Sensitive Information

Cloudflare’s edge servers vulnerability was identified by Google’s Project Zero Team a few years ago. The flaw, which was related to a buffer overrun, caused Cloudflare’s servers to return memory containing private information (e.g., HTTP cookies, authentication tokens, HTTP POST bodies). To make things worse, some data were cached by search engines. Thankfully, a research team discovered the issue and it was dealt with quickly. But if this were to happen to your organization, you might not be so lucky.

How Can You Prevent Cryptographic Failures?

• Be data privacy and regulations compliant. Ensure you comply with the privacy laws and the regulatory requirements like the General Data Protection Regulation (GDPR), and the PCI Data Security Standard (PCI DSS).
• Apply the policy “if you don’t need it, get rid of it.” Never store sensitive data you don’t need or cache sensitive information.
• Secure your data. Make sure your app encrypts all data in transit using the TSL protocols. Stored sensitive data must be encrypted and passwords should be salted hashed (i.e., only stored salted password hashes, never plaintext passwords).

OWASP Top 10 — #3: Failing to Secure Your System Against Injection Attacks

Code injection is an attack consisting in injecting malicious code into a vulnerable application. The main types of code injection attacks are:

• SQL injection. Used to modify a database query to provide falsified data or modify database entries.
• Cross-site scripting (XSS). Malicious scripts are injected into a trusted website, often with the goal of attacking other users.
• Shell injection. Used to execute operating system commands to compromise the targeted app and its data.

With more than 274,000 identified occurrences, injection vulnerabilities enable attackers to access secure pages and information as if they were trusted users.

Common Injection Vulnerabilities

• Unvalidated and unsanitized user inputs are allowed. The user can supply data without waiting for the application to validate, filter, and sanitize their inputs.
• Allowing dynamic queries. Using dynamic queries or non-parameterized calls (queries without defined handling parameters) will enable the attacker to change the intent of a query by inserting a malicious SQL command.
• Hostile data. A malicious code (hostile data) is added into a form or a webpage to execute unauthorized commands or access additional, sensitive records. The structure and malicious data in dynamic queries or stored procedures are included in the SQL code injection.

Check out OWASP’s list of mapped CWEs for additional information.

Real Life Example: Big Names Globally Found Their Sensitive Data Breached

Have you ever heard of the Panama Papers scandal? This security incident was one of the largest data breaches in history, leaking more than 11 million offshore financial records (including those of several current and former world leaders). One of the identified possible attack vectors was an SQL injection flaw. This just goes to show that when an injection hits, it can hit very hard and have devastating results for those involved.

How Can You Prevent Injection Attacks?

OK, you probably don’t have an offshore bank account and you’re likely not involved in dodgy activities abroad. But this particular incident goes to show that no matter how big and powerful you are, you could still find yourself in a difficult place because of an unmitigated security vulnerability. This is why it’s always better safe than sorry and do everything within your power to prevent vulnerabilities on the OWASP top 10 list from affecting your business and applications:

• Build a safe API. Using object relational mapping tools (ORMs) that will enable you to avoid writing SQL queries to build your API. No SQL queries, no more risks of SQL injections. If you prefer, you can also opt for parameterized queries so that the goal of a query remains unchanged even if the attacker inserts a malicious SQL command.
• Use database controls. Enforcing specific regulations to ensure that each user gets access only to the data he’s entitled to view, modify and/or delete. This will prevent mass exposure of data in case of a successful SQL injection.
• Include code review. Ensure that a code review is included in your development process to identify new injection flaws before releasing your application.

OWASP Top 10 — #4: Planning (and Implementing) Insecure Design Flaws

Failing to plan for a secure design is a plan to fail. Insecure design flaws represent a new category entry in 2021. With more than 262,000 occurrences, this vulnerability category focuses on the risks related to weaknesses in an application’s design and architecture. Why? Because a perfectly implemented app is still vulnerable to attacks if its design is insecure. And an insecure design can’t be fixed by a flawless implementation.

Common Insecure Design Vulnerabilities

• Passwords stored as plain text. Passwords should never be stored in online databases, period. This type of vulnerability often happens when no specific credential-related security tactics are discussed and agreed upon during the architecture and design phase.
• The error message generated contains sensitive information. A self-generated error message resulting from an incorrect SQL query could show the malformed query and expose the logic behind it.  
• Credentials insufficiently protected. The application transmits or stores authentication credentials using an insecure method making it easy for the attacker to get access to the user’s account and password.

Be sure to check out OWASP’s complete list of mapped CWEs.

Real Life Example: McAfee Design Vulnerability Leaves Databases Vulnerable

In 2021, a denial of service (DoS) vulnerability was identified in McAfee’s Database Security product for Windows devices. The vulnerability was due to a misconfiguration in the user interface, which allowed a remote user to trigger a denial of service (DDoS) attack or destroy database data. This was easily fixed by updating to the next version of the database.

How Can You Prevent Insecure Design Issues?

As proverb attributed to Aristotle says, “well begun is half done.” This vulnerability is one you have to prevent at a very early stage of the development process.

• Build a good user story. When you’re collecting the requirements from the stakeholders, include a thorough list of functional and non-functional security requirements and controls. The user story (a concise, easy to understand description of a software feature from an end-user’s perspective) should also document the application’s potential flaws.
• Include security in the development process. Implement a secure development lifecycle involving your application security from the beginning and including security integration tests.
• Secure and segregate your layers and libraries. Ensure application tier layers and network layers are well separated and use a secure design pattern library.

OWASP Top 10 — #5: Neglecting Security Misconfigurations

A security misconfiguration happens when any security control (e.g., settings, technical error messages, configuration changes) aren’t properly configurated, not secured or poorly documented. This will put your system or data at risk of attack.

This category has over 208,000 CWE occurrences and it’s a direct consequence of the recent shift into highly configurable software. Flexible configuration can be cool however, the more freedom you have to configure your software, the easiest it is to make mistakes.

Common Security Misconfiguration Vulnerabilities

• Default usernames and passwords. Enabling or using default account IDs and/or passwords without first changing them it’s a rookie mistake. The same goes with including credentials in the code you’re publishing: just check on GitHub and you’ll be amazed by how many people are still making this mistake.
• Cloud services permissions. Incorrectly configured permissions on cloud services can give an attacker quick and easy access to sensitive data.
• Unnecessary features enabled or installed. If you don’t use it, get rid of it. Unused ports, services, pages, accounts, or privileges are security hazards that increase your attack surface.
• Improperly configured or disabled security features. Why bothering with including cool security features in your web app when, once released, they’re either disabled or incorrectly configured? It’s like installing big security bolts to your front door and then leaving the door open.
• Out of date software. Did you install the latest update and patches? Did you enable and correctly configured the latest security features? If the answer to one of these two questions is no, you may have an issue.
• Poor error handling. An error message can be over informative and display sensitive information to the users or attacker.

Complete list of mapped CWEs.

Real Life Example: AWS3 Misconfiguration Results in Leaked Company & Customer Data

Due to a poorly secured Amazon AWS S3 bucket, the Australian broadcasting corporation suffered a major leak of customers’ password hashes, emails, logins, videos, and licensed content requests. The issue was detected one week after AWS issued formal advice on how to secure S3 buckets. Sometimes, a small delay in fixing security issues can wreak havoc and cause a lot of headaches for you and your customers.

How Can You Prevent Misconfiguration Issues?

• Secure your systems via a hardening process. Develop and automate the process of deploying a separate and secure environment with the same configuration but different credentials.
• Use a basic platform. Sometimes less is more. Get rid of all unnecessary bells and whistles.
• Review and update. Include a task in your patch management process that’ll force you to regularly review and update the configurations related to updates, patches, and cloud storage permissions.

OWASP Top 10 — #6: Keeping on Using Vulnerable and Outdated Components

There’s no doubt that vulnerable and outdated components represent a huge security risk to organizations and their data. (A chief example of this point was the devastating Eternal Blue exploit of legacy Microsoft operating systems back in 2017 that resulted in the Wannacry ransomware attacks.)  And organizations have acted upon it in the last few years as the category registered slightly more than 30,000 occurrences.

Common Vulnerable and Outdated Components Vulnerabilities

• Outdated, vulnerable, unsupported software. Sticking to old software is never a good idea. This includes everything from legacy operating systems and database management systems (DBMs) to APIs and libraries.
• Not running vulnerability scans. Not scanning your components regularly for vulnerabilities and ignoring security news can leave your application exposed.
• Patching only every few months. This vulnerability is typically seen in organizations where patching is a quarterly task instead of something that it’s done more frequently when necessary. 
• No compatibility tests. Developers aren’t performing compatibility tests on the updated, upgraded, or patched libraries.

A completed list of mapped CWEs

Real Life Example: Attackers Exploited the Log4j2 Vulnerability Before It Was Publicly Known

Who didn’t hear about the Log4j2 vulnerability? This is a remote code execution (RCE) vulnerability in the open-source Apache logging package Log4j2 that was exploited even before being publicly reported in December 2021. As this was a component widely used by major online service providers like Amazon, Microsoft, IBM, and Google, it could have had a major impact worldwide.

How Can You Prevent Having Outdated Resources in Your IT Environment and Web Apps?

• Components inventory. Ensure you make a regular inventory of the versions of client-side and server-side components and their dependencies. Check sources like the common vulnerability and exposures (CVE) and the National Vulnerability Database (NVD).
• Install only official components. Use only official sources (i.e., digitally signed software, codes downloaded directly from a publisher’s or manufacturer’s website, etc.) and secure links to obtain components. Ensure that the packages you install are properly signed.
• Monitor unmaintained components. Keep an eye on libraries and components that aren’t maintained or don’t have security patches. A typical example are IoT devices: most of them are rarely/never patched or updated after their release. 

OWASP Top 10 — #7: Ignoring Identification and Authentication Failures

Previously known as broken authentication, identification and authentication failures are related to the risk of attacks due to inadequately managed credentials and login sessions. With more than 130,000 registered occurrences, it deals with weaknesses in authentication and session management allowing attackers to gain unauthorized access to accounts and data.

Common Identification and Authentication Failures Vulnerabilities

• No protection against attacks. Attackers can easily use brute force or automated attacks (where the attacker has a list of user IDs and passwords) to get to the data.
• Passwords are poorly managed. Default or weak passwords are allowed, the password recovery procedures aren’t good enough, passwords are stored in plain text, and no multifactor authentication is used.
• User sessions. The session is reused after login or it’s exposed. Or, even worse, the user sessions and authentication tokens are incorrectly invalidated at the logout.

A completed list of mapped CWEs

Real Life Example: Attackers Used an Insecure Password to Gain Access to South Carolina Taxpayers’ Data

A few years ago the South Carolina’s Department of Revenue suffered a massive hack due to a weak password used by an employee. As a result, 3.6 million taxpayers’ social security numbers and 387,000 credit card numbers were stolen.

How Can You Prevent Identity- and Authentication-Related Issues?

• Improve your password management processes. Ensure you implement multifactor authentication (or even passwordless authentication measures), and don’t allow the usage of default or weak passwords. The National Institute of Standards and Technology’s (NIST) Digital Identity Guidelines can help you establish a proper password policy.
• Implement effective protection against attacks. Limiting the number of login attempts, performing weak password checks, monitoring failed logins and suspicious activities and behaviors can reduce the risks of DDOS and credential-focused attacks.
• Use a session manager. This will enable you to generate new random session IDs after a login. Never keep the session identified in the URL and be sure to set it to invalidate after logout. 

OWASP Top 10 — #8: Failing to Verify the Integrity of Software and Data

The Software and data integrity failures category is related to software updates, critical data, and CICD pipelines without sufficient integrity checks, allowing the attackers to exploit them to distribute malicious software. As another new entry in 2021, with nearly 48,000 occurrences, it’s related to the failure of verifying the integrity of updates and patches prior to implementation.

Common Software and Data Integrity Failures Vulnerabilities

• Applications relying on updates from unverified sources. This includes all plugins, libraries, or modules updates coming from unverified and untrusted sources or repositories.
• Applications with auto-update functions. Automatic updates are convenient however, very often don’t include a thorough integrity check leaving the door open for attackers.
• Insecure deserialization. This was one of the categories present in the 2017 OWASP top 10 vulnerabilities list. It’s related to flaws caused by data encoded or serialized into a structure that’s visible to an attacker and open for modifications. Thus, an attacker will be able to manipulate the serialized data to include malicious input into the application code to increase the attack surface.

A completed list of mapped CWEs

Real Life Example: SolarWinds’ Failure to Secure Their Supply Chain Led to One of the Worst Breaches in History

Who can forget one of the most sophisticated cyber attacks in history — the SolarWinds hack that was all over the news in late 2020-early 20221? Attackers managed to access a development server used by many Fortune 500 companies and insert malicious code into installations packages like updates and patches. As a result, when the customers downloaded them, they’d also download the malicious code. Once installed, these patches created backdoors used by the attacker to install more malware to spy on the victims.

How Can You Prevent Software and Data Integrity Failures?

• Secure your updates. Implementing digital signature mechanisms and ensuring that libraries and dependencies are only using trusted repositories will avoid the installation of tampered software.
• Control and review. Implementing a review process for code and configuration changes will minimize the chance of infected code being introduced into your software.
• Integrity checks. Ensure that no unsigned or unencrypted data is sent to untrusted clients without an integrity check or digital signature to detect any unauthorized change.

OWASP Top 10 — #9: Lacking Proper Security Logging and Monitoring

In 2017, this category was called insufficient logging and monitoring and it’s only moved up one spot on this year’s list. As the name implies, the category security logging and monitoring failures refers to failing to adequately monitor and keep sufficient suspicious activity records that could lead to slower incident responses.

Common Security Logging and Monitoring Failures Vulnerabilities

• Poor or nonexistent logging of suspicious activities. From unchecked APIs and application logs to unlogged failed logins and suspicious events, these poor practices can lead to undetected vulnerabilities.
• Lack of alerts. Warnings and errors help you to early identify potential issues. But when penetration testing and scanning tools don’t trigger alerts, or their alerting thresholds are ineffective, then they’re useless.

A completed list of mapped CWEs

Real Life Example: British Airways Was Unaware of a Breach Until Notified by a Third Party

In 2018, British Airways was hit by a major data breach that remained undetected for nearly two months when the company was finally alerted by a third party. Among the sensitive information accessed by the attacker, there were the personal data of more than 429,000 customers and staff. This included names, addresses, and payment card numbers. Learn the lesson: always check and log suspicious activities.

How Can You Prevent Security Monitoring and Logging Failures?

• Log everything that matters. Ensure you register every login, access control, and server-side validations failure with enough information to identify suspicious or malicious activities easily. Store your logs long enough to be able to do a forensic analysis when needed.
• Use good log data coding formatting. Logs create a lot of noise — make sure that your logs are formatted for compatibility with log management systems.
• Audit and monitoring. Implementing effective monitoring and an audit trail with integrity controls for high-value transactions will help you minimize the chance of data breach and code infection.
• Incident response. Adopt an incident response and recovery plan. As a reference, you can use NIST’s Computer Security Incident Handling Guide.

OWASP Top 10 — #10: Overlooking Server-Side Request Forgery (SSRF) Vulnerabilities

Another new entry. This one was taken from the results of the OWASP’s top 10 community survey. With a bit more than 9,000 occurrences, server-side request forgery it’s the last of the 2021 OWASP top 10 vulnerabilities.

Common Server-Side Request Forgery Vulnerabilities

• URL fetching. While allowing users to point an application to a specific URL is convenient for end-users, this practice comes at a cost in terms of security. It enables an attacker to get the server to send them sensitive information or lets them modify sensitive data — even when a firewall or other security mechanisms protect it.
• Cloud services. The usage of cloud services and particularly complex architectures can increase the severity of vulnerability to SSRF.

A completed list of mapped CWEs

Real Life Example: Microsoft Exchange SSRF Vulnerability Led to Fraudulent HTTP Requests and Authentication

In 2021, Microsoft announced an Exchange server vulnerability that was used for an SSRF attack against governments and private organizations. After the attackers gained access to the servers, they deployed web shells — scripts that enabled them to steal data and perform additional malicious actions.

How Can You Prevent It?

• Network layer prevention. Use separate networks for remote access resources and block all non-essential traffic by implementing deny by default network policies.
• Application layer prevention. Disable HTTP redirections, enforce a URL schema, and sanitize and validate all inputs from clients.

Final Thoughts on the OWASP Top 10 Vulnerabilities

Web applications, like all software, are constantly updated. New versions are released and, along with new features you also get new vulnerabilities sometimes. These vulnerabilities can lead to everything from network and data compromise to noncompliance issues and penalties. This is why it’s paramount for every business to be always up to date with the latest top vulnerabilities.

A web app security breach can cost you and your organization a lot and it will hurt your business’s reputation. And even if applications are becoming more and more secure, attackers are always finding new flaws.

Going through the OWASP vulnerabilities list and learning how to prevent those vulnerabilities, it’s a step forward on your road to securing your web applications. At the end of the day, it’ll always be a cat-and-mouse game. But if you keep an eye on the top 10 vulnerabilities and know how to fix them, your apps will already be more secure. Take your security to the next level now!