Why is API Protection Getting Worse?

Application Programming Interfaces (APIs) are now the preferred choice when it comes to facilitating connections in the cloud because they can be used to quickly and efficiently create consistent, feature-rich applications. A recent Enterprise Strategy Group (ESG) report found that more than half of web apps and websites will use APIs over the course of the next two years. But security is not keeping pace.

According to the Cloud Security Alliance’s ‘Top Threats to Cloud Computing’, APIs now pose the second biggest threat to cloud security, second only to identity, credential, key and access management. It’s rise up the threat charts directly corresponds with its popularity but also the voracity of attacks. Back in 2017, APIs came in at number three in the CSA chart and then fell all the way to number seven in 2019. Their rise back up the chart would therefore indicate both that they are now far more firmly on the attacker’s radar and that current approaches to protecting is inadequate.

The rising API threats

The market is seeing new API threat vectors emerge, for example, with 41 percent of respondents in the ESG survey reporting that they are finding it difficult to keep up. Almost a third had experienced injection attacks, nearly a quarter the exploit of misconfigured APIs and a fifth were subjected to Account Takeover (ATO) and OWASP Top 10 attacks. Such attacks had very damaging repercussions, with 40 percent going on to experience downtime while other impacts included damage to the brand, revenue losses, non-compliance.

These attacks are increasingly successful because API security has unique requirements. Indeed, they’re not strictly speaking attacks at all but rather exploits that turn the functionality of the API against it. As there is no signature or rule breaking involved this makes it difficult for traditional solutions to detect this activity, so using web application solutions to do the job has limited success.

IPS or next gen firewalls or application security tools such as a WAF or bot mitigation tool are unable to detect and capture the anomalous behaviour that indicates an API is being abused.  However, the ESG survey found that more than a third are unaware of this fact and think these tools are adequate. When they do suffer an attack, 38 percent admitted to then reinvesting in security solutions, resulting in a bloated stack. So, while many recognise that APIs are fundamental and need securing, there remains confusion over how best to approach the problem.

The API lifecycle

The problem is that many solutions only look to secure part of the way in which APIs operate rather than looking at the entire lifecycle, from their creation to their ongoing management and retirement. At the development stage its common to use a specification to ensure consistency but another survey carried out in 2021 found that 76 percent of businesses did not use API specifications for all their APIs with 27 percent followed no standard at all. Among those that did, their approach was ad-hoc, with 36 percent not using a tool to document their API specifications. Manual rather than automated practices were also used, with 58 percent manually verifying conformance and 64 percent manually tracking and maintaining their API inventory, a practice that is not only likely to result in errors but will also prove unsustainable as APIs use ramps up.

APIs are also dynamic. Once coded, they’re spun up and updated over time which means they keep changing and can easily be misconfigured. They’re also highly numerous so keeping track of them can be problematic. If they aren’t recorded in an inventory this can quickly give rise to zombie or shadow APIs that are then unmonitored and easy prey for attackers. The inventory should be updated on a continuous basis, yet 37 percent found the inventory process challenging, according to the ESG report.

APIs that are unprotected can expose data through error messages that show too much information or display obfuscated information. This enables an attacker to determine how the app works, so the minimum of metadata should be transferred to reduce risk.

Adopting a unified approach

Given that the API needs to be protected and monitored from development through to deployment and beyond, it makes sense to seek to secure these mechanisms at each stage of the process, requiring a comprehensive approach.

Unified API Protection (UAP) seeks to develop, discover, detect, and defend the API. At the development stage when APIs are created, it uses predefined API-specific tests based on OWASP threat definitions and advanced techniques to find and fix vulnerabilities during pre-production. By ‘shifting left’ and addressing security here, the likelihood of vulnerable or poorly coded APIs being deployed is lessened.

With regards to the network, unified protection sees the business carry out an attack surface sweep which views APIs through an attacker’s eyes to identify and prioritise issues.  A real time continuous inventory of APIs is then carried out to uncover and remediate those that may be exposing sensitive data, not following specification definitions, or failing to use authentication best practices.

Often API solutions only focus on detection. While this is a crucial part of unified protection, the approach taken is to utilise hundreds of predefined behavioural fingerprints, rules, and machine learning models to not only detect but also prevent automated attacks and exploits such as those defined by OWASP. This sees potential threats flagged for rapid analysis and response on a per-policy or per-API or app basis. Rather than handing off security to the WAF, an agentless API-specific solution can enable the organisation to handle this detection and response.

As our dependency on APIs continues to grow, it’s imperative that we begin to think differently about how we secure these mechanisms. The increase in attacks against API infrastructure and the rise in the threat level identified by the CSA both indicate that current approaches aren’t working, so isn’t it time we did things differently?