DEVOPSdigest

The OWASP Foundation updated the API Security Top 10 list(link is external) for 2023, outlining the most critical security risks for APIs in production. The updated guidance highlights just how much the API security landscape has changed since the original list was published in 2019 — including the rapid rise of business logic attacks (BLAs). Three of the top five categories on the Top 10 list are now related to business logic abuse, compared to just two in 2019. The updated list underscores the fact that if organizations want to bolster their API security, implementing safeguards capable of detecting and remediating abuse of business logic needs to be a priority.

Why Are Business Logic Attacks Uniquely Dangerous?

As modern applications increasingly take on the role of automating business workflows, business logic becomes more reliant on the code that developers wrote and pushed into production. While developers are good at implementing the functionality, manual security checks are often left out. Attackers will seek out gaps to exploit business logic vulnerabilities.

What's more, the implementation of the business logic within the application can also introduce unintended consequences. Risks emerge when multiple inputs and data-driven components are tied together through a web of APIs that are implemented without considering potential security vulnerabilities or misconfigurations. Worse, some existing application components that were originally developed as internal applications can be exposed when they're migrated to a cloud-based environment.

Unfortunately, while most organizations understand the threat posed by common attack tactics like phishing and ransomware, BLAs are not as well known, particularly as they can come in many forms. A BLA functions by exploiting the intended functionality of an API or application. An abuse might be as simple as using the same coupon multiple times on an online retail site, or as complex as tricking an API into providing confidential data in response to an unauthorized request. Because these actions involve engaging with the application's intended function rather than targeting its technical vulnerabilities, security alerts are seldom triggered.

Abuse of business logic can result in financial losses, regulatory penalties, and reputational damage. Traditional security measures like Web Application Firewalls (WAFs) are typically used to secure APIs from known patterns — such as SQL injection — but these solutions are not equipped to detect or prevent BLAs. As such, a significant share of businesses may be vulnerable to business logic exploits and not even know it.

Increasing awareness is critical, and the decision to include multiple BLA-related trends in the new OWASP Top 10 list is an important first step in helping organizations recognize the level of risk that applications and APIs are exposed to.

New OWASP Guidance on BLAs

The change in the way OWASP lists API exposures is particularly noteworthy. On the previous list, one of the categories related to BLAs was called "mass assignment." It was a broad term that encompasses multiple potential vulnerabilities. If an attacker has access to a broken object property level, they can manipulate a property or change the user object's property to grant themselves administrative privilege. That's part of mass assignment, but it isn't the whole picture. Excessive data exposure is another element — one that requires different steps to mitigate. In the new list, mass assignment and excessive data exposure are essentially absorbed into a single category called Broken Object Property Level Authorization (BOPLA).

Still, one of the interesting things about the new OWASP guidance is that all three of the trends that pertain to business logic use the word "broken." Broken Object Level Authorization (BOLA), Broken Object Property Level Authorization, and Broken Functional Level Authorization are all vulnerabilities that organizations need to account for, but the word "broken" implies something was working, and then it broke. That isn't the case. Attackers aren't "breaking" the solutions designed to stop BLAs, they're exploiting the fact that they often don't exist. Or, in other cases, they're exploiting a risky implementation.

For example, an API endpoint normally used for fetching a single user's data might be overloaded to generate a report on multiple users. This design can expose an endpoint to broken object level authorization exploits. If organizations don't even know where their APIs are deployed or what data they are accessing, they can't apply the right authentication and authorization controls.

How to Address the API Threats Listed by OWASP

Most organizations are still in the early stages of understanding and developing an API security strategy, which means they often lack a nuanced approach for protecting APIs — especially from complex threats that target business logic. Identifying the APIs present within the environment and working with developers to apply the right controls is an essential first step toward addressing this issue.

The responsibility for solving this problem does not lie solely with security teams. BLAs don't exploit weaknesses in security solutions. Because it involves business logic — often involving a vulnerability in implementation or a mistake inadvertently introduced by the developer — coordination and communication between the security, developers, and DevOps teams is essential for identifying and remediating errors. Mistakes will inevitably happen and it's unrealistic to expect perfection from developers. But it becomes a significant problem when security teams lack a clear line of sight into potential misconfigurations and vulnerabilities.

OWASP highlights vulnerabilities that pertain to authorization and authentication at the object level, property level, and functional level, and these are issues that need to be fixed during the build, testing, and staging processes. Thorough testing should lay bare errors in the business logic, allowing developers to fix the problem at the root. At the same time, they can work closely with security teams to ensure that they know what they will likely need to look for in the event a vulnerability escapes notice and slips through the cracks.

Limit BLA Exposure through Visibility and Communication

There is a reason BOLA is listed first on OWASP's new API Security Top 10 list. BOLA and other types of attacks that exploit business logic will continue to be a leading challenge for organizations, especially as many still do not realize how vulnerable their APIs truly are. There is no simple, one-size-fits-all solution to the challenge of BLAs — addressing them requires the cooperation of multiple teams across the organization. By understanding risk, implementing thorough testing procedures, and ensuring open visibility and communication between the development and security teams, businesses can significantly limit their exposure to the trends highlighted by OWASP's new guidance.