Organisations are seeing a proliferation of APIs (Application Programming Interfaces) across their cloud environments (single, hybrid and multi-cloud) as they expand their use of microservices and create new cloud-native applications. They’re the tool of choice for developers because each API includes all necessary commands, payload, and data needed to facilitate machine-to-machine interactions and they rarely malfunction.
But this sprawling API footprint represents a significant security challenge. The prevalence of APIs across diverse locations makes it difficult to inventory, manage and protect them and insecure APIs are vulnerable to cyber attack. APIs are a top target for attackers because they have access to sensitive data residing on applications and backend systems. Calls made to APIs can be subverted to enable attackers to access this data so the stakes are extremely high. In fact, over 95% of organisations experience API-related security incidents and the vulnerability of a network, its APIs and associated endpoints is directly proportional to the number of deployed APIs which makes it vital to secure them.
Why other tools are ineffective
Typically, organisations concentrate on implementing technical measures to detect and prevent API exploitation. This often involves deploying infrastructure like content delivery networks (CDNs) or Web Application Firewalls (WAFs) to mitigate attacks. However, these solutions may face challenges as they are not specifically designed to withstand the types of attacks typically directed at APIs.
Most automated attacks result in hundreds of thousands if not millions of IP addresses being blocked which has the potential to cripple or even crash a WAF. When attackers see their attack being blocked, they re-tool, often shifting to a different batch of IP addresses, which then creates another influx of additional IPs to block. Secondly, the number of WAF rules that are needed to block an attack based on IP or other expressions will slow down the WAF. It becomes difficult to manage and, if there are false positives, screening through these to identify the IP addresses that belong to legitimate users is nearly impossible.
An API-specific approach therefore needs to be taken and one which recognises the unique challenges involved. The OWASP Top 10 API Security Risks, recently updated, serves as a crucial guide to understanding how these attacks manifest themselves. Broken Object Level Authorisation (BOLA) remains a prevalent attack, emphasising the importance of adhering to API authentication best practices to safeguard data. Authentication coding errors may attackers unauthorised access or elevated privileges, underscoring the need for diligent development practices.
Automated versus long tail attacks
Automated attacks unique to APIs, like API4 focusing on unrestricted resource consumption, aim to disrupt services through denial of service (DoS) ausaltor escalate resource usage, leading to significant operating costs. Similarly, API6 sees unrestricted access to sensitive business flows, such as order mechanisms, abused again allowing the attacker to place excessive orders for goods or services.
Such attacks demonstrate the vital link between API security and bot mitigation, which is why any approach needs to be able to not just rate limit but actively monitor and address automated attacks. API attacks can vary considerably, however. We are increasingly seeing automated attacks that seek to quietly slip under the radar and use the API to mine for data, scrape content, or harvest credentials, for instance, or set up fake accounts to carry out fraud. Such attacks are not volumetric, so they will not trigger a WAF and the only way of spotting them is through behavioural analysis.
So, what does an effective approach to API security look like? Firstly, it’s essential to establish an inventory of all deployed APIs across the network and in the cloud. The discovery process needs to be carried out internally and externally to provide a hacker’s eye view so that all public-facing APIs are captured. It’s a process that needs to run continuously so that APIs continue to be logged throughout their lifetime as they are updated, annexed to third parties, or replaced to prevent any shadow (undetected) or zombie (redundant) APIs from being overlooked.
Those APIs then need to be monitored to look for suspicious activity, but simply monitoring for traffic surges is insufficient. Protecting APIs requires two forms of threat detection and response. There’s the immediate need to curtail an aggressive attack and this will typically utilise a host of defence techniques from attack blocking to rate limiting, geo-fencing, and even deception by using a fake response to cause the attacker to pivot or exhaust their efforts. However, other more subtle attacks that aim to accumulate data are less obvious and can only be detected using bot mitigation techniques. To monitor these, it is necessary to compare the types of requests being made against a catalogue of malicious behaviours, known bad infrastructure and attack tool kits to create a behavioural fingerprint for that attack that can then be tracked in real time. It therefore pays to verify the threat intelligence an API vendor has at their disposal.
Security starts in development
The final piece of the API lifecycle management is compliance. To remain secure, the API needs to comply with the build specifications or protocol used, such as SOAP, REST or GraphQL, and there may well be industry-specific regulations that need to be complied with, such as the Payment Card Industry Data Security Standard (PCI DSS), data protection regulations such as GDPR or new regs such as the Digital Operational Resilience Act (DORA). The most effective way of doing this is to put governance processes in place during development. Introducing shift left testing, whereby testing for security and compliance happens earlier in the development process, ensures coding issues are addressed pre-production, making it much more cost-effective to remedy problems and less likely that issues will arise once the API goes live.
Focusing on API security as a standalone issue rather than a subset of web application security must be the way forward if organisations are to avoid falling victim to these attacks. Real-time detection and native prevention in the form of API-specific solutions that can map and track malicious activity are key to defend against fraud, business logic attacks, exploits and unintended data leakage. Attackers have already switched their attention to the API attack surface and are continually evolving novel ways of compromising this technology, so defenders, too, now need to address the unique challenges of managing APIs in the cloud.
Andy Mills is VP of EMEA for Cequence Security and assists organisations with their API protection strategies, from discovery to detection and mitigation. He’s a passionate advocate of the need to secure the entire API lifecycle using a unified approach. Prior to joining Cequence, he held roles as CRO for a major tax technology provider and was part of the original worldwide team of pioneers that brought Palo Alto Networks, the industry’s leading Next-Generation Firewall, to market. Andy holds a Bachelor of Science Degree in Electrical and Electronic Engineering from Leeds Beckett University.