APIs have delivered velocity and competitive advantage to companies of all sizes with IDC research calculating that 10-50% of enterprise revenue is derived from APIs, making them the interface of choice for data interchange between applications.
But this versatility is not without its price. APIs are equally attractive to attackers because they provide ready access to the backend systems holding sensitive data. As adoption grows, so too does the API attack surface, potentially creating a ticking timebomb because of the poor security afforded to these middlemen.
According to the Enterprise Strategy Group (ESG), application environments will see a significant step change in the next two years. While 35% of organisations currently run their apps over public cloud i.e. IAAS, this will almost double to 67%, and while 39% run these apps over microservices today, this will rise to 71%. It’s a similar story with API adoption. Today, 28% of web apps and websites use APIs but that will rise to 57%. But security isn’t keeping pace.
Why protecting APIs is a struggle
APIs are stateless in nature and include the command, payload, and content, making them challenging to secure. Typically developed iteratively, they evolve over time, and this can see their footprint fluctuate or previous iterations continue to persist. Updates tend to be performed weekly or even daily, resulting in multiple earlier versions and if these aren’t taken down or kept track of via an automated inventory they then can become shadow or zombie APIs and possible targets for attack.
Protecting APIs is no easy feat, which is why many security teams have adapted existing solutions such as Intrusion Prevention Systems (IPS), next gen firewalls, or app security tools such as a Web Application Firewall (WAF). However, these tools are unlikely to spot and flag malicious activity because while some may contain insecure code the vast majority won’t but can still be taken over. Commonly referred to as ‘Living off the Land’ (LotL) attacks, this sees the API’s own functionality used against it.
As a LotL attack doesn’t involve the use of signatures or break any rules, such activity is unlikely to be detected. If we look at the top attack method according to the OWASP Top 10 – Broken Object Level Authorisation (BOLA formerly IDOR) – the attacker simply must understand the business logic of the API to gain legitimate access to data. This means that reverse-engineering an API can provide the insight needed; there’s no need to exploit a vulnerability, so it could be argued it’s not an attack in the traditional sense.
Trust in tools misplaced
What’s concerning is that many aren’t even aware that these tools are performing badly. The same ESG survey found that 46 percent use multiple tools because they think this increases the protection offered and 38 percent chose to add in yet more tools if these weren’t performing as expected, adding to the technology stack and the headache of monitoring, and maintaining this. More than a third thought their solutions offered complete protection even though they weren’t designed to provide API security.
At this point it’s also worth mentioning that there’s a lot of confusion in the marketplace. An API gateway, for instance, should not be considered an API security tool. It enables the business to discover and track its APIs but does not discover or remediate coding errors nor does it stop or block API attacks. Indeed, an API gateway can exacerbate the problem by acting as a single point of failure that, if compromised, then provides access to all the APIs it routes.
There are numerous examples of companies falling foul of API attacks such as Account Takeover (ATO), for example, and as APIs become more entrenched in supply chains, so the problem grows. The attack against MailChimp earlier this year should serve as a warning of how far a well-orchestrated attack can reach. It saw the compromise of API keys used to provide account access and the attackers then actively sought out finance and crypto clients. One of these was Trezor, a maker of cryptowallets. A phishing email was then sent out to Trezor customers who were urged to reset their accounts using a cloned Trezor application.
Adopting a unified approach to API protection
Such attacks indicate that modern services built on API infrastructure are not adequately protected. It is only a matter of time before we begin to see API abuse ramp-up, which is why Gartner has already warned that APIs are set to become the most frequent attack vector. To counter this, we need to rethink our approach to API protection before it is too late.
To begin with, it’s necessary to discover and create an accurate runtime inventory of APIs that documents when these are spun up, updated, or retired. This not only provides visibility but also the means to track APIs to ensure they comply with best practice. Armed with an inventory you can begin to focus on detection and looking for tell-tale signs of an attack or Indicators of Compromise (IoCs).
Those tools we mentioned above can help here if the attack is based on known threats or involves a brute force attack, but the chances are it will be more subtle in approach, requiring behavioural analysis. Comparing log-in success and failure rates to accounts, for example, and benchmarking these within your industry, can help determine ATO attacks. Or perhaps a single username is being used but is originating from multiple IP addresses, again an IoC.
Of course, some APIs will contain insecure code which is why much of the emphasis to date has been on ‘shift left’ and the need to introduce security at the development stage. It’s this focus that most API security tools take but in doing so they fail to allow for the fact that perfectly coded APIs can still be susceptible to attack. Yes, APIs should be tested and secured before go-live, but coding errors or misconfiguration can happen after go-live too. In fact, the Cloud Security Alliance has just moved API misconfiguration from seventh to third place in its list of ‘Top Threats to Cloud Computing’, suggesting current approaches are not working.
The missing part of the puzzle which the security sector has until recently baulked at is prevention. Utilising machine learning, however, it becomes possible to spot a malicious attack masquerading as legitimate behaviour and to block attacks in real-time. Various techniques can then be used to create subterfuge, obfuscate potential targets, and deflect attacks. Taken together, all six elements – discovery, inventory, compliance, detection, prevention, and testing – then create a security approach that covers the entire API lifecycle offering unified API protection and our best hope when it comes to defusing the API attack surface.