OWASP Compliance

Broken access control climbed up to the #1 spot on the list from #5 in the previous Top 10. That means that it is the biggest problem for development teams when it comes to security breaches. In its findings, OWASP reported that 94% of applications tested contained this issue. The biggest CWEs related to this vulnerability are:

• CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
• CWE-201: Insertion of Sensitive Information Into Sent Data
• CWE-352: Cross-Site Request Forgery

What Is Broken Access Control?

This security vulnerability allows access to private resources for unauthorized users. Attackers can go around any security protocols in place to access sensitive systems and information.

What Is the Impact of Broken Access Control?

It has become the most common vulnerability on the OWASP 2021 Top 10 list. Weak authorization and authentication methods allow for this security risk. However, broken access control can separately break down into 34 CWEs. It accounts for more issues in the OWASP survey than in any other category.

Cryptographic failures now rank in position #2 from #3 on the previous OWASP Top 10 list. This vulnerability used to be known as “Sensitive Data Exposure.” The new name focuses on the root cause of the issue instead of a broader symptom like the old term.

What Are Cryptographic Failures?

Cryptographic failures often lead to data breaches. Examples of threat vectors include things like a lack of HTTP headers, weak cryptographic algorithms, transmitting data in clear text, and so on. The data breached can include everything from simple passwords to health records and credit card numbers.

What Is the Impact of Cryptographic Failures?

Cryptographic failures can often cause sensitive data breaches, as well as other kinds of system compromises. Notable breaches in recent memory include the Red Cross data breach of January 2022.

The goal is to make them extremely difficult to occur in the first place. This requires proper design, secure code, consistent testing, and integration security into your workflow.

Now in the third position, this category includes cross-site scripting, which was previously its own item ranked #7 on the OWASP Top 10.

What Are Injection Issues?

An injection is when an attacker sends specifically crafted data designed to force the application to execute commands that it’s not intended to execute. For instance, a SQL injection can potentially extract unexpected data—even an entire database—or even alter or delete data.

What Is the Impact of Injection Issues?

For many years, this was the #1 issue according to OWASP. It remains important and all too common. In fact, among the applications tested, OWASP found 274,000 injection occurrences. However, injection issues are also highly preventable.

Avoiding injection attacks means taking a close look at what you may have done wrong. This ranges from not validating user-supplied data to hostile data used within object-relational mapping (ORM) search parameters that allow for sensitive record extraction.

The biggest types of injection attacks to watch out for include:

1. CWE-79: Cross-Site Scripting
2. CWE-89: SQL Injection
3. CWE-73: External Control of File Name or Path

This new category centers around risks inherent in design flaws. OWASP developed this category as a result of the shift left methodology that requires incorporating security testing and threat modeling into workflows and architecture. Beyond starting security testing earlier, it’s important to examine the code. Flag anything that can’t be well secured in favor of a more secure design.

What Is Insecure Design?

Insecure design involves the development and testing teams failing to anticipate threats while developing code. Threat evaluation and adhering to best security practices also affect design security. This category is different from insecure implementation in that it has more to do with risks related to design and architectural flaws.

A secure implementation might have an insecure design that still renders a web application vulnerable to attacks and exploits. Insecure design is a broad category representing different weaknesses expressed as missing or ineffective control design.

What Is the Impact of Insecure Design?

In today’s development world, insecure design is more common than you might think. That’s why DevSecOps — incorporating security into the development lifecycle — is crucial now. In other words, you can’t just test your way to secure software. You have to start building software that’s more secure.

Here are some examples of attack scenarios that leverage insecure design.

• Verbose error messages leading to path transversal.
• A secure implementation might have an insecure design that renders a web application vulnerable to attacks and exploits.
• An insecure design prevented PC users and gamers from purchasing new Nvidia GPUs at recommended retail prices in a recent real-world incident.

Now in position #5 from #6 in the previous Top 10, security misconfiguration includes XML external entities (XEE). The increasingly configurable nature of software contributed to this category’s place on this list. A notable instance of recent misconfiguration was the 2023 FAA NOTAM outage — proof of how critical an issue it is.

What Is Security Misconfiguration?

This category includes insecure implementation due to some form of misconfiguration. Think of it as when a vital security setting is configured incorrectly or not at all. A simple example of this is not resetting the default password. These oversights and mistakes create security gaps for would-be attackers — especially with container-driven deployment that has many opportunities for misconfiguration.

How Common Is Security Misconfiguration?

Examples of security misconfiguration are things such as out-of-date software, missing security hardening, unnecessary features, and default accounts with unchanged passwords. Many things can be easily overlooked, so OWASP recommends a repeatable security configuration process to mitigate risk. What does that look like? Whenever possible, configuration files should be part of version control and included in peer reviews.

This category used to be called “Using Components with Known Vulnerabilities” in the ninth spot in the previous OWASP Top 10. OWASP admits that this is difficult to test with no common vulnerability and exposures (CVEs) including CWEs. However, it ranked second in the OWASP community survey thanks to big incidents frequently in the news such as those involving Log4j and SolarWinds.

What Are Vulnerable and Outdated Components?

Using components you don’t know about or components with nested dependencies can lead to risks. Other examples include unsupported, vulnerable, or out-of-date software such as third-party libraries, old versions of open sources, and so on.

Regularly scanning for vulnerabilities, removing unused or unnecessary features, and maintaining up-to-date software can help mitigate risks associated with vulnerable and outdated components.

What Is the Impact of Vulnerable and Outdated Components?

There are lots of tools and attacks that take advantage of these known issues. Making sure that you’re up to date with patches and versions helps you protect the application against these attacks.

As an example, Log4j suffered a zero-day vulnerability that affected Cloudflare, Steam, iCloud, Twitter, Tencent QQ, and the Java Edition of Minecraft in 2021.

Known before as “Broken Authentication,” this category falls to 7th from the 2nd position in the previous Top 10. It also includes CWEs more closely related to identification failures. Security risks associated with this category are mitigated by standardized framework adoption that helps better control ID/Auth issues.

What are Identification and Authentication Failures?

Basic identification and authentication failures happen when an application doesn’t correctly identify or secure a user’s login credential, identity, or permissions or fails to maintain ID controls throughout a user’s session. Vulnerabilities occur when a system uses plain text or weakly hashed credentials, has weak credential recovery methods, or does not invalidate session IDs, for example.

What Is the Impact of Identification and Authentication Failures?

Since this category includes common user activities such as logging into applications and user sessions on websites, these risks are often among the most commonly encountered. A tactic known as “credential stuffing” makes use of these kinds of attacks to leverage any passwords obtained in leaks.

Features such as multi-factor authentication and more robust password checks can assist with risk mitigation.

This new category centers around assumptions about code and infrastructure made in relation to critical data, software updates, and CI/CD pipelines that don’t verify integrity. It includes the 2017 topic “Insecure Deserialization.”

What Are Software and Data Integrity Failures?

Software and data integrity failures include problems such as insecure parts of a CI/CD pipeline or even content delivery networks (CDNs). For example, an application might include an auto-update function that changes the code. This introduces opportunities for attackers to gain unauthorized access and use their own malicious code.

What Is the Impact of Software and Data Integrity Failures?

Because these issues involve infrastructure and code without protections against integrity violations, security experts expect an increase in these types of violations. Items such as home routers and device firmware don’t require signed firmware to update. This vulnerability would require fixes in a future version.

Insecure deserialization is also a significant concern. It’s a common opportunity for DoS attacks. It occurs when user-controllable data is deserialized by a website. Insecure deserialization can enable an attacker to manipulate serialized objects to pass harmful data into the application code.

Security logging and monitoring failures used to be called “Insufficient Logging & Monitoring” and also appeared frequently in the OWASP community survey. Though difficult to test for, these kinds of failures can drastically affect a variety of aspects such as forensics, incident alerting, and visibility.

Logging helps trigger monitoring and response; if it’s incorrect, the security posture breaks down. The visibility helps development teams better address issues earlier.

What Are Security Logging and Monitoring Failures?

This kind of failure involves not identifying and/or responding to would-be threats to or hostile attempts against systems. A classic and frequent example of this is repeated login failures due to an incorrect password.

Security logging and monitoring failures can have significant impacts on an organization, including a lack of visibility into security incidents. Without proper logging and monitoring, it can be difficult to detect and respond to security incidents in a timely manner.

Many regulations, such as HIPAA and PCI-DSS, require organizations to maintain detailed logs of their security activities. Failure to do so can result in non-compliance and fines. Additionally, without proper logging and monitoring mechanisms, it’s significantly harder for organizations to detect and mitigate breaches, which costs them time and money.

Security logging and monitoring failures can lead to other issues as well. Most notably, they can trigger Broken Access Control — the #1 item on the 2021 OWASP Top 10 list. Establishing robust and comprehensive SAST and DAST strategies can help mitigate these failures.

What Is the Impact of Security Logging and Monitoring Failures?

While security logging and monitoring failures happen in their own right, they can lead to other issues, too. Most notably, they can trigger Broken Access Control — the #1 item on the 2021 OWASP Top 10 list. Establishing robust SAST and DAST strategies can help mitigate these failures.

Despite the low incident rate in OWASP data, the severity of impact is high. Community surveys show that it is the #1 item of concern. These kinds of attacks are easy to execute successfully and can produce particularly nasty effects.

What Is Server-Side Request Forgery?

These flaws commonly occur when web applications retrieve remote resources, but do not validate user-supplied URLs. Attackers can then force the application to behave differently — even when shielded by a VPN or firewall.

An example of this would be an attacker creating their own web page hosted on their own server and using that to alter the behavior of an application. In fact, many older consumer routers have this exact problem – you can change the password without authentication by creating your own web page and submitting a new password.

OWASP and developers have seen an uptick in Server-Side Request Forgery due to the following:

• Increasing rate of URL fetching
• Wider adoption of cloud services
• Architecture complexity