API Business Logic Vulnerabilities

API business logic vulnerabilities are logic flaws in an API’s design and implementation that lead to deviations from the expected, planned, and normal API use and behavior. They’re examples of subpar design and development practices.

How do they occur? Can you prevent and find them, and how? Have they been exploited in the wild? Does the OWASP API security project cover them?

Read on to learn the answers to these and other questions about API business logic vulnerabilities.

API Business Logic Vulnerabilities in Depth

Business logic vulnerabilities is an umbrella term that refers to a range of unanticipated cybersecurity outcomes caused by misplaced logic. The logic appears sound but leads to places you didn’t intend to. In those unforeseen situations and states, APIs act irregularly, sometimes even erratically, and can end up being misused or abused.

Since these phenomena do not occur exclusively in the business context, the more technically accurate term would be logic vulnerabilities. However, here, we stick to the more common name, business logic vulnerabilities.

API logic is the way the API works, that is, the rules that govern the API’s behavior and use. When we say rules, we mean logic implemented through code, such as “if p, then q.” This set of rules is unique to each API. One example is, “If a customer buys three items, they get a 20% discount.”

That’s one big reason logic vulnerabilities are difficult to discover: their uniqueness. A successful vulnerability discovery, in this case, requires a thorough understanding of the API and its quirks and idiosyncrasies, which do not readily fit into general and expected patterns of security risks.

Another big reason is that API business logic vulnerabilities are not your typical technical vulnerabilities. When you search for a technical API vulnerability, such as injection, it’s easier to spot. It’s a more or less glaring oversight of good security and coding practices, so you know what you’re looking for and how to find it.

In contrast, a business logic vulnerability doesn’t exactly scream, “Find me, I’m here!” It’s an integral part of the way API works, but it’s an undesirable integral part. The trick is to see that it’s undesirable.

It’s worth noting that “business logic” is not a term used identically by everyone. Some differentiate between business logic and application logic or, in our case, API logic.

Business logic defines the rules that guide an organization to achieving its business objectives. For instance, business logic dictates the prices, discounts, and customer permissions, rights, and limitations.

API logic then must implement these rules in the software context. However, what makes it different from business logic is that not every aspect of API logic is about business objectives or even business at all.

For instance, sending a four-digit OTP code to a user’s mobile device when the user requests access to her account is not business logic. It’s how APIs work (unless they’re public), regardless of whether they’re developed for business or any other purposes.

Conversely, applying a discount code to a specific number of purchased products is an example of business logic.

However, we’re not making that distinction here. The reasons are the following:

• In practice, it’s often difficult to distinguish between API and business logic, and we’re not interested in strictly conceptual distinctions.
• Treating different logic flaws leading to unexpected security outcomes as belonging to the same category simplifies the discussion of logic-related API vulnerabilities, and it appears to be the prevalent way they’re discussed in the industry.

Examples of API Business Logic Vulnerabilities

Too Much Trust in Client-Side Controls

In this case, developers assume that users will interact with the API, or the web app relying on the API, exclusively through the predefined interface. Consequently, they implement only client-side security controls.

However, attackers can use proxies to intercept API transactions and change, say, a price parameter to buy something at a much lower price than the original.

Unfiltered Unconventional Input Values

If the API doesn’t prevent users from submitting unconventional values, such as negative numbers or extremely long string values, it suffers from a business logic vulnerability. Threat actors can use this weakness to, say, change product prices to negative numbers.

In this scenario, too, the problem is the unfounded belief that users won’t try to submit unexpected values.

Insufficient Workflow Validation

Say developers assume that users will always follow a given sequence of requests, so they do not validate the correct order. In such a scenario, hackers can change the order of API requests and tinker with POST and GET methods to complete a checkout process without paying for a product.

The common element in these three examples is the underlying assumption about user behavior regarding the API. The obvious moral of the story is: Don’t ever, for any reason, assume anything about the user, no matter what, no matter where, or who, or who you are with, or where you are going, or where you’ve been ever, for any reason whatsoever.

Yes, that was a Michael Scott quote, a bit altered for our purposes.

API Business Logic Incidents

The USPS Data Exposure

This security incident was disclosed in November 2018. It was revealed that a USPS API exposed information about approximately 60M users due to flawed business logic and broken authorization (API5:2023 Broken Function Level Authorization).

The API allowed businesses, advertisers, and bulk mail senders to track package and mail campaign data in near real time. The problem was that any regular user could see this data and, on top of that, access information—email address, street address, phone number, and much more—of other regular users had she decided to query the system for these details. Moreover, she could do that without any sophisticated technical or hacking skills and tools.

Other security issues aside, this is an example of business logic vulnerability because USPS assumed that regular users would access only their own accounts and data and did nothing to prevent unauthorized access to other user’s data.

The Venmo Data Exposure

This data exposure example is not a typical security incident. It’s more of a risky default behavior of Venmo, the popular payment app.

Between 2016 and 2019, a few security researchers warned about the privacy risks entailed by Venmo’s API. The API allowed anyone who sent GET requests to see information about the latest 20 transactions, regardless of who the users that made them were. Moreover, you didn’t even need to have a Venmo account to see this information.

In other words, the API was accessible to literally anyone who knew how to look beyond the GUI. In this case, that wasn’t an oversight. Venmo intentionally made the API public, assuming no one would use it for data scraping or nefarious purposes.

With the ability to make two requests per minute, one researcher could query and download the information of 115,000 transactions in just one day.

Among others, he could use this data to research the payment and daily habits of different users—track you over time, understand whom you interact with the most, learn what you purchase most often, and similar—and use this knowledge in a social engineering attack.

Even without the threat of social engineering, knowing that such information is accessible to the prying eyes of someone whom you’ve never met in your life is highly disturbing.

Business Logic Vulnerabilities and OWASP API Security Top 10

Are business logic vulnerabilities covered by the OWASP API Security Top 10, the highly authoritative list of the most threatening API security risks?

OWASP API Security Top 10 does not explicitly mention business logic or logic flaws. The closest it comes to them verbally and conceptually is API6:2023 Unrestricted Access to Sensitive Business Flows. That may lead to the conclusion that API6:2023 is the only OWASP API security category that discusses (though partially) this security threat.

Indeed, the sensitive business flows that API6:2023 talks about are business logic flaws. They:

• Are easily exploitable
• Are common but not easy to detect
• Are susceptible to automated cyberattacks
• Require hackers to have a good understanding of the business

An example of this vulnerability is the unrestricted purchase of limited-edition, highly sought-after sneakers.

Suppose an online reseller’s platform assumes that no one would buy all the available quantities at once. If, consequently, it doesn’t set any limitations to prevent this type of purchase, malicious actors can exploit this logic flaw. That’s approximately what a sneaker cook group did in an Apple Pay shadow API abuse.

This logic flaw is a typical business logic vulnerability. It can be misused and abused without exploitation of any technical issues.

However, Unrestricted Access to Sensitive Business Flows is not the only OWASP Top 10 API logic-related security risk. In certain cases, authorization issues can also be considered business logic vulnerabilities.

For instance, if you can bypass authorization controls by intercepting API traffic, tamper with requests, assign yourself the role of an admin instead of a regular user, and utilize admin privileges to abuse both the API and the application relying on it, you have discovered and exploited a business logic vulnerability.

This is a business logic issue because it doesn’t stem from a lack of authorization or weak authorization controls. What causes the security problem is not a technical issue but flawed logic, that is, the assumption that no user would look beyond the GUI to bypass access controls.

That’s why logic vulnerabilities are difficult to detect by automated scanners and in general. Here, you don’t look for missing or weak security controls but for the underlying logic of how users are expected to interact with the API. And to understand that, you must understand the inner workings of the API.

In conclusion, OWASP API Security Top 10 does relate to business logic vulnerabilities, but only partially. To understand and discover this type of security issue, you must go beyond the OWASP API Security Top 10.

API Business Logic Vulnerability Discovery and Prevention

Quirky logic doesn’t have to lead to enormous problems. However, you must always fix it, even if you can’t see how it can be exploited.

To prevent business logic vulnerabilities, you need to:

• Create clear design documents.
• Weave in security into API design—make it secure by design.
• Document API rules and assumptions.
• Implement modification checks—input validation and similar checks for data integrity—across the board.
• Enforce a zero-trust model so every API request must be authorized and validated repeatedly.
• Employ server-side controls—they are necessary.

To discover business logic vulnerabilities, you must:

• Conduct regular and frequent API security testing, including API penetration testing and fuzzing, using smart, modern, specialized security solutions developed to find business logic vulnerabilities, such as Equixly.
• Implement real-time API monitoring, which allows you to detect unusual, suspicious, and anomalous behavior.

Conclusion

API business logic vulnerabilities are sloppy logic or accidental logic flaws that result in security problems. This category of vulnerabilities includes issues such as excessive trust in client-side controls, unfiltered unconventional input values, and insufficient workflow validation.

One clear example of a business logic incident was the USPS data exposure, but keep in mind that many more happen regularly. Some are publicized and known, others not.

Whatever the case, one thing is for sure: You must root out API logic flaws. To achieve that, you need to apply measures such as server-side controls, a zero-trust approach, and API security testing and monitoring.

Reach out to learn how Equixly enables you to discover API business vulnerabilities and what mechanisms it uses to achieve this feat. We’d be thrilled to help.

Carlo De Micheli

Director of Product Marketing

Carlo is a versatile professional with extensive international experience. His enthusiasm for innovation extends across cybersecurity, automotive, and aerospace, where he actively engages in pioneering projects. Holding a technical background in aerospace engineering and supplementing it with independent studies in programming and security, Carlo has organized and presented at international conferences and established tech startups related to the sharing economy and fashion before embracing marketing and sales.

Zoran Gorgiev

Technical Content Specialist

Zoran is a technical content specialist with SEO mastery and practical cybersecurity and web technologies knowledge. He has rich international experience in content and product marketing, helping both small companies and large corporations implement effective content strategies and attain their marketing objectives. He applies his philosophical background to his writing to create intellectually stimulating content. Zoran is an avid learner who believes in continuous learning and never-ending skill polishing.