Updated OWASP Top 10 for API Security Underscores the Challenge of Mitigating Business Logic Attacks
November 29, 2023

Lebin Cheng
Imperva

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.

Lebin Cheng is Head of API Security, Office of the CTO, at Imperva
Share this

Industry News

March 27, 2025

webAI and MacStadium(link is external) announced a strategic partnership that will revolutionize the deployment of large-scale artificial intelligence models using Apple's cutting-edge silicon technology.

March 27, 2025

Development work on the Linux kernel — the core software that underpins the open source Linux operating system — has a new infrastructure partner in Akamai. The company's cloud computing service and content delivery network (CDN) will support kernel.org, the main distribution system for Linux kernel source code and the primary coordination vehicle for its global developer network.

March 27, 2025

Komodor announced a new approach to full-cycle drift management for Kubernetes, with new capabilities to automate the detection, investigation, and remediation of configuration drift—the gradual divergence of Kubernetes clusters from their intended state—helping organizations enforce consistency across large-scale, multi-cluster environments.

March 26, 2025

Red Hat announced the latest updates to Red Hat AI, its portfolio of products and services designed to help accelerate the development and deployment of AI solutions across the hybrid cloud.

March 26, 2025

CloudCasa by Catalogic announced the availability of the latest version of its CloudCasa software.

March 26, 2025

BrowserStack announced the launch of Private Devices, expanding its enterprise portfolio to address the specialized testing needs of organizations with stringent security requirements.

March 25, 2025

Chainguard announced Chainguard Libraries, a catalog of guarded language libraries for Java built securely from source on SLSA L2 infrastructure.

March 25, 2025

Cloudelligent attained Amazon Web Services (AWS) DevOps Competency status.

March 25, 2025

Platform9 formally launched the Platform9 Partner Program.

March 24, 2025

Cosmonic announced the launch of Cosmonic Control, a control plane for managing distributed applications across any cloud, any Kubernetes, any edge, or on premise and self-hosted deployment.

March 20, 2025

Oracle announced the general availability of Oracle Exadata Database Service on Exascale Infrastructure on Oracle Database@Azure(link sends e-mail).

March 20, 2025

Perforce Software announced its acquisition of Snowtrack.

March 19, 2025

Mirantis and Gcore announced an agreement to facilitate the deployment of artificial intelligence (AI) workloads.

March 19, 2025

Amplitude announced the rollout of Session Replay Everywhere.

March 18, 2025

Oracle announced the availability of Java 24, the latest version of the programming language and development platform. Java 24 (Oracle JDK 24) delivers thousands of improvements to help developers maximize productivity and drive innovation. In addition, enhancements to the platform's performance, stability, and security help organizations accelerate their business growth ...