Why business logic abuse is a major threat

Earlier this year one of the largest ever cases of business logic abuse was detected when a botnet across over 11 million unique IP addresses was used against the login Application Programming Interfaces (APIs) of a Fortune 500 hospitality provider based here in the UK. The attackers sought to use credential stuffing to identify valid user accounts and obtain payment details and were able to avoid triggering the usual security measures for two reasons.

Firstly, they conducted the attack on one of the busiest days of the year for the organisation, Valentine’s Day, so that the high volume of calls being made to those APIs was not deemed unusual. Secondly, because the attack abused business logic vulnerabilities, it wasn’t strictly an attack at all. The calls made to the company’s APIs were perfectly legitimate requests to login to accounts.

Legitimate and syntactically correct, these calls are difficult to detect. For example, during the attack residential proxy networks were used to imitate genuine traffic so that even though the attack resulted in 28 million security events these were only equivalent to three events per unique IP address and so did not trigger rate limiting or raise the alarm. As a result, the security measures businesses usually have in place, such as intrusion prevention systems, web application firewalls (WAFs) or security gateways, would have struggled to spot the attack.

In this particular instance the attack was thwarted because the business was not wholly reliant on IP-based detection systems but was able to use behavioural-based detection. By monitoring the traffic to the APIs and analysing their headers and payloads and using local models to determine behaviour and intent, a behavioural fingerprint of the attack could be created. This was then used to apply a policy to block the malicious traffic without the need to upload an IP address list.

What the attack demonstrates, however, is just how ambitious these assaults are becoming. Business Logic Abuse is now the top type of attack directed against APIs, accounting for over a a quarter of attacks (27%). But businesses are still playing by the old rules, relying on security solutions that look for blatant high-volume attacks or the exploitation of vulnerabilities such as coding errors when attackers now increasingly opt for more subtle techniques. Business logic abuse sees the attacker study the APIs of the business for weaknesses and susceptibilities in their design that will allow them to subvert its functionality to manipulate workflow processes and/or gain unauthorised access.

Recognising the threat these attacks pose and the difficulties businesses have in detecting them, as well as the fact they transcend any one technology and don’t fit into standard taxonomies, the OWASP Project set up a working party earlier this year dedicated to mapping the issues. It has just released the first ever Business Logic Abuse Top 10 which highlights the most common ways processes are being abused based on real-world examples and ranks them according to frequency, impact and exploitability.

The list reveals how developers can fail to anticipate how functions can be accessed, altered or combined to achieve malicious ends and the importance of deactivating those functions. For instance, topping the list are Lifecycle and Orphaned Transitions Flaws (BLA1:2025) which can occur when the temporary artefacts created in a process i.e. sessions, tokens and sub-flows fail to be rescinded once the parent process has been completed. As these artifacts then continue to persist, they remain callable and can be used by an attacker to “replay steps, resurrect closed processes or corrupt system state,” according to the OWASP Project enabling the attacker to tap into previous flows.

Business logic attacks can be also be used to max out a service through repeat requests. Logic Bomb, Loops and Halting Issues (BLA2:2025), which are second on the list, are circular flows found in the business processes that APIs automate. These can be exploited to create a Denial of Service type scenario whereby API calls are able to exhaust CPU and memory or cause the service to crash. The Billion Laughs attack against the IBM Sterling Gateway is cited as a prime example, whereby an attacker was able to send a malicious payload to the gateway causing it to process entities repeatedly, exhausting resources.

Another well-publicised issue concerned O2. A researcher discovered a flaw in the telecom operator’s network that could enable an attacker to see the location data of a user as well as IMSI and IMEI data. The issue, which is thought to have existed since February 2023 and was resolved in May 2025, was due to Data Oracle Exposure (BLA5:2025) and Missing Roles and Permissions Checks (BLA6:2025) resulting in the SIP headers revealing too much data.

These examples all serve to illustrate how varied business logic abuse can be as well as how easily these vulnerabilities can go unnoticed. Many are just waiting to be discovered and exploited, making it imperative that organisations take action to secure their APIs.

Stopping business logic abuse begins in the production stage. Shift left testing will help reduce the potential for these attacks by ensuring the logic only allows the API to be used in a predefined way so that it cannot perform actions that could have a negative impact. However, even APIs designed with the best authentication and controls that function seamlessly and as expected can be subverted. It’s for this reason that testing APIs pre- and post-production is no longer sufficient.

Effective bot management is vital in reducing the automated abuse of APIs and to maintaining a secure predictable behaviour. By monitoring all the traffic to an API and looking for anomalies in that behaviour it becomes possible to detect these attacks. Utilising the four pillars of detection – tools, infrastructure, credentials and behaviour – the business can then accurately identify business logic abuse as it happens and prevent these attacks natively, as shown in the case of the UK hospitality provider.

Looking to the future, the likelihood is that attackers will continue to leverage business logic vulnerabilities to attack APIs. And it’s an attack vector that could well grow if AI is then used to discover these issues and explore how they could be used for malicious purposes. There will, of course, always be vulnerabilities but it is possible to prevent their exploitation if the business knows how and what to look for.