Op-Ed: Think your carefully coded API is secure? Think again!

The so-called “shift-left” strategy has gained ground. This strategy sees security testing carried out solely in the development process rather than throughout the entire release cycle. While shift-left has allowed departments to develop and roll out their own APIs, it assumes that developers are happy to self-check their own work and make any changes that might be required.

While this might seem logical, it poses a serious danger as it creates a false sense of security. An assumption is made that if an API has gone live, it must be secure, and that may well not be the case.

Determined attackers

The unfortunate reality is that while a shift-left strategy can deliver some benefits, neither it nor any other security measures can ward off persistent, automated attacks against APIs. If the assets connected to them are sufficiently valuable, attackers will persist.

Often, attackers actually use an API’s own functionality against it in attacks known as business logic abuse. This is because even if an API is coded correctly, adheres to the API specification it is designed against, and has been fully tested, it can still be probed and compromised.

Research conducted by Cequence in 2022 found APIs were being subjected to automated business logic abuse in a number of different ways. In one case, more than 3 billion shopping bots were used to target well-formed APIs with a dense network of highly volumetric and geographically distributed fuzzing payloads.

More than 290 million malicious gift card requests were made using enumeration based on fuzzing the numeric patterns on APIs that support payment and checkout microservices. The potential losses to businesses as a result of such attacks are significant.

A multi-attack strategy

VIEW ALL

Although well-coded and secured APIs can still be attacked, it does take more effort on the part of the attacker. With this in mind, many will typically use multiple methods from the OWASP Top 10.

There have been examples where cyber criminals have, for instance, used a combination of API2 (Broken Authentication), API3 (Broken Object Property Level Authorisation) and API9 (Improper Inventory Management). This allows them to perform a detailed analysis of how target APIs work, how they interact with each other, and the expected outcome. That information was then used for malicious purposes.

In another example, a large-scale enumeration attack was executed against a third-party inventory API. The inventory search API supplier notified the security team of the company in question and requested help to stop the attack.

The resulting investigation mapped the attack to OWASP API4 (Unrestricted Resource Consumption) and API5 (Broken Function Level Authorisation). The attackers first targeted the web API before moving to the mobile API, which provides similar information.

That attack targeted the inventory API directly, without hitting any other app or web function. Originating from residential proxy IP addresses, the attack rotated through 153,000 unique product and SKU combinations while scraping 61,000 ZIP codes and 33,000 products.

Unfortunately, web application firewall (WAF) and content delivery network (CDN) mitigation steps were ineffective. The attack was only stopped by policies that effectively blocked 85.9 million requests. That is a situation no organisation wants to face.

Spotting an attack

In that example, the company was alerted by its provider; however, many organisations may not be sure how they can spot attacks against what they believe to be secure APIs. Unfortunately, web application firewalls (WAFs) or bot prevention tools are ineffective at preventing API-specific attacks for a range of reasons.

WAFs use signatures to detect known vulnerabilities as described in the OWASP Web Application Top 10 Threats list. This means they will struggle to find and block attacks that appear legitimate, and they are unable to address the entire API protection life cycle.

Bot tools rely on JavaScript instrumentation to collect the telemetry required to understand and block an attack. As an API is clientless, it cannot be instrumented in this manner. As a result, those that believe their APIs are secure and rely on traditional web security tools are lulled into a false sense of security.

Achieving effective API security is an ongoing and very challenging task. Security teams need to understand that even the best-written and managed APIs can still fall victim to an attack. The answer is to remain constantly vigilant and ready to act as soon as malicious activity is spotted anywhere in the supply chain.

Glen Maloney is the ANZ country lead at Cequence Security.