Recently, a less obvious issue that is starting to get more attention is the vulnerability of Application Programming Interfaces (API). Although not at the top of most CISOs’ to-do lists that might be the point; securing APIs is still a topic many organisations don’t think deeply about until it is too late.
APIs Are Everywhere
Web traffic is usually thought of as traffic between a web application or website and a human being. In fact, according to a 2019 estimate from Akamai, up to 83% of this traffic is to and from APIs, a second layer of software on which websites and applications depend. This is overwhelmingly machine-to-machine communication that happens invisibly in the background.
The rise in API traffic is a consequence of the way these have become a critical part of the digital landscape. Even smaller businesses probably depend on dozens, while in enterprises it can run to hundreds or even thousands at a time. Some are internal APIs, developed in-house, while many others are from external sources, used to enable and draw data from a wide range of data services.
Cyber criminals have tracked the importance of APIs, resulting in a growing number of attacks in which they have featured in the attack chain. According to Akamai, cyber attacks targeting APIs grew 137% in 2022. Examples include:
- A 2021 LinkedIn API flaw exposed the data of 700 million users to web scraping.
- A Twitter API weakness compromising the data of 5.4 million people.
- A 2022 attack on Australian telecom company, Optus breached the personal data of almost 10 million customers.
The Optus incident is revealing. First, it seems that the API was working correctly, and the breach wasn’t a conventional hack at all – the company simply left the data exposed through the API. Second, the data loss led to Optus being extorted. Most organisations fear extortion after a conventional ransomware attack. The Optus breach showed how APIs could be a simple back door to achieve the same end.
What Is an API?
For many years, APIs were programming shortcuts that made it easier for application developers to interact with things like operating systems, for example, the various Windows APIs. Programmers didn’t need to know anything about the underlying hardware and could instead use a Windows API call to do the hard work.
The arrival of e-commerce in the early 2000s changed this forever as APIs became a way to access data too. The pioneers were Salesforce and Amazon but soon many others were using APIs to sell access to data. A famous example is Google Maps, a huge mapping database that many organisations license for use inside their own apps through an API.
This shows how APIs operate as standardised interfaces that make it easier to connect an application to something proprietary such as a database. But it stands to reason that if you’re making it easy to connect to data this becomes vulnerable should the API have a weakness that allows unauthorised access.
An Invisible Problem
According to the recently updated list of common API weaknesses tracked by OWASP, many of the vulnerabilities afflicting APIs are similar to those affecting conventional web applications. For example, number two on the list is ‘broken authentication’ which relates to things like brute force and credential-stuffing attacks through the API.
In many cases, organisations don’t even know they are using a vulnerable API. This can happen for a variety of reasons, starting with the sheer number of APIs. When organisations used small numbers of APIs, keeping on top of them was easy; when that rose to hundreds, the management task multiplied beyond the capability of their tools and teams to keep pace.
As with any software, the APIs also keep changing, which results in new vulnerabilities. Third-party APIs only compound this. A developer incorporated an API inside an application but forgot to document it. The result? The whole problem of shadow APIs can eventually turn into zombies, namely APIs that are no longer being updated.
A final problem is that many API issues involve the exploitation of legitimate but poorly designed API functions, or where an API has been left in an exposed state (for example, without correct authentication) by accident.
Is There a Solution?
There is a tendency to see API security as something only larger companies need to worry about. In fact, any organisation using APIs is at risk, including SMBs. Today, organisations typically protect their APIs with a mixture of web application firewalls (WAFs) API service gateways, or some form of access or authentication control. The catch is that these systems weren’t developed for API security and often lack the features needed to protect and manage them.
A priority for any organisation should be to conduct some kind of audit of which APIs they are using, including undocumented ones. Short of buying a dedicated API tool, this can be a big job on an ongoing basis. Meanwhile, many API issues occur at a third-party developer level, which is almost impossible for a small organisation to detect. Unfortunately, this means that there is no easy API security fix, which probably explains why the issue has persisted.
A note of hope is that more sophisticated API detection, management and security is finding its way into mainstream security tools such as e-commerce gateways used by smaller organisations. One way to access this technology is through managed service providers (MSPs) offering API security as part of their service.
