Application Programming Interfaces (APIs) now underpin much of the digital services we consume, but many businesses have rolled them out in such numbers and at such speed that they’ve struggled to document them. The APIs then become ready targets for attackers who are able to study and subvert them to gain access to the valuable data they gatekeep.
The answer to governing this API footprint, according to the security industry, is to carry out discovery to net those APIs that have been operating off-radar and to decrease the attack surface.
Discovery can be used to reveal shadow APIs (those the business didn’t know about), zombie APIs (those that have persisted and which may or may not serve a purpose), and those deemed non-compliant (missing specifications). But the process can vary in its thoroughness. It may not seek to create an inventory of internal, external, and third-party APIs, for example, or may not operate on a continuous runtime basis, thereby governing APIs throughout their lifecycle.
However, discovery shouldn’t be regarded as a means of managing risk in and of itself. Once you have documentation, you need to look at those APIs and assess the risk they represent. This can be difficult because, if the business is going it alone and trying to adhere to a framework like the OWASP API Security Top 10, it’s going to struggle to identify which threats to prioritise. Knowing whether account takeover (ATO) or broken object level authorisation (BOLA) is more pressing is hard; and giving equal weight to too many attack types negates the purpose of the exercise, which is to appropriately and proportionately apply security.
Of course, in many ways determining the risk an API poses will only become known once it is deployed and comes under attack. Theory will only get you so far, but by that time it’s too late, which is why relying on a discovery-based approach is flawed. Focusing on discovery can see the business fail to monitor what’s happening in the API traffic and to spot any changes in the calls being made to APIs, which could be indicative of an attack. Blindsided, the business is then caught in a reactive state.
Early detection is therefore key, but what do you do if you suspect an attack? The general approach has been to offload enforcement to the SOC or development team, or to use Content Delivery Networks (CDNs) or Web Application Firewalls (WAFs) for enforcement. The problem here is that these solutions are not designed to handle API attacks. They struggle to detect and deal with business logic abuse, for instance, which sees the functionality of the API used against it.
A far more logical solution is to handle detection and mitigation natively in line with the API, which allows policies to be customised and response workflows created. This can allow attacks to be stopped in flight using a variety of tactics, from rate limiting to blocking, or deception, whereby the attacker is sent down blind alleyways to frustrate them or to max out their resources.
In addition, it’s advisable to adopt a ‘shield right and shift left’ approach. This involves both stopping the attack in its tracks while simultaneously working cross-functionally with security and development teams to get any API issues resolved. In this way it becomes possible to minimise the window for attackers to do anything harmful while simultaneously improving the attack surface.
One tier-one telecom operator adopting this approach was able to do precisely that. The operator started with continuous runtime discovery and inventory, capturing over 30,000 API endpoints. It then determined which had serious vulnerabilities, such as APIs that did not require authorisation, those that were transmitting sensitive data inappropriately, or those containing known vulnerabilities. By shielding right and shifting left, the operator was then able not just to block access attempts but also to carry out virtual patching of its API base to prevent access to its APIs with outdated authentication algorithms.
Such use cases attest to the value that going beyond the discovery phase can confer. But there’s also another very pressing need for organizations to bolster their API defences; and that is AI.
AI and APIs
Both generative AI and agentic AI use APIs to retrieve information and tools. In the case of agentic AI, which is able to function autonomously, the agent has a two-sided exchange. A set of inbound APIs is used to perceive the world around it, to understand the task at hand, and to collect the data needed to complete the task, with additional APIs used to rationalise the problem and come up with possible solutions. A second set of outbound APIs is then used to test those solutions in a real-world context, measure their success, and learn from the outcomes. This creates two sides to the same coin and significantly raises the risk of compromise.
The dependency of AI on APIs to facilitate these learning journeys makes those APIs a key target for attackers. Stopping those attacks will require much better visibility over both the APIs calling the AI agent and those the agent is consulting for answers. That means we need to know not just that those APIs exist but also how effectively they are protected in terms of the level of authorisation required to access them. At the present time, many APIs have little to no authentication built in, or are using outdated methods. It’s also very difficult to determine the authentication and access controls present in third-party APIs, which means securing AI interactions is going to be challenging.
It’s for these reasons that businesses must stop regarding API security as simply a matter of discovery. Discovery, inventory, and compliance are undoubtedly important, but these are baseline activities that fail to equip the business with the means to monitor, detect suspicious activity, and defend their APIs. It’s only by embracing runtime visibility, native protection, and real-time mitigation that we can meet these dynamic attacks with the necessary dynamic response and ensure these APIs don’t scupper AI.
The author
Mohammad Ismail is VP of EMEA, Cequence Security
