The application programming interface (API) has been one of the great developments in software, unlocking the agility and collaboration that defines modern innovation. They’re everywhere, and they’re essential; APIs provide a way for applications to communicate with each other and while it's not immediately obvious, we use them multiple times a day. When we want to share a post from one social media platform to another, for example, APIs enable us to do that. When we want to buy something online or through an application, APIs will connect the website or application to a payment processor. When we book a flight and hotel recommendations appear on the confirmation page—an API puts them there. APIs have allowed us to realise the possibilities of open banking, and as LLMs and other types of generative AI become ever more important to businesses, it is APIs that will enable enterprises to integrate those capabilities into their systems.

APIs are such a basic part of our everyday technology use that most don’t even realise they’re there. They’re specifically designed to be discreet access points that give third parties direct access to partners’ data and technology stacks. But that can be a double-edged sword. For all their benefits, APIs can grow quickly and surreptitiously throughout an environment. In a short time, enterprises come to possess a vast and elusive network of APIs across their environment. These sprawling endpoints are often hard to track, monitor, and test, with misconfigurations and security flaws a common problem—as they’ve become a core part of modern business, they’ve also become a serious security risk.

A short history of the API

APIs have their roots in the 1960s and 70s when mainframe computers used them to enable communication between machines. They continued to develop as ways for computer systems to talk to each until, in 2000, Roy Fielding proposed the Representational State Transfer (REST) API architecture, which uses HTTP protocol methods to establish a lightweight, stateless form of communication. From there, giants like Amazon and eBay began adding APIs to allow third-party applications to integrate with their systems. This was then followed closely by the likes of Facebook, Twitter, and Google, who used APIs to develop entire application development ecosystems centered around their services. Fast forward to today and APIs are a core part of ubiquitous digital transformation, enabling collaborative innovation across a range of sectors and industries and often serving as part of the internal architecture of enterprise applications themselves.

However, as with so many innovations, security considerations often lag behind new functionality. APIs are now a major cause of security incidents, between the blithe enthusiasm for adoption and the inattention that is paid to the risks they pose if left unchecked.

When enterprises close a door, they open an API

As we said before, APIs are also data access points—not easily spotted by casual users but open to anyone who knows how to find them. That speaks to their function, but it also reveals one of the ways in which they get forgotten about and left as unmonitored points of entry just waiting to be exploited. Just one unsecured endpoint can lay an entire organisation low, like a bank vault with a well defended steel-clad exterior but an unlocked service door next to it.

Even recently, API incidents have felled some of the largest companies in the world this year alone. Early in 2024, the popular social media site—X, formerly Twitter—was breached when hackers exploited a vulnerability in an API that let them completely bypass authentication measures. From there, hackers were able to access a range of private user data. X quickly patched the vulnerability and conducted an audit of their security.

However, this isn’t the first time an API has exposed the company. A few years ago, when X was Twitter, another API breach resulted in a potentially massive leak of user information. In fact, between June 2021 and January 2022, another vulnerable API allowed attackers to farm personal details from accounts. While it was known that some data had been taken, it wasn’t until the end of 2022 that a vendor emerged on the dark web selling the data of 200 million Twitter users, extracted from the API vulnerability. While Twitter patched the vulnerability when it was discovered, their monitoring was not sufficient to detect the massive scraping of data by malicious actors. That failure initiated a variety of state and federal level investigations both in the US and elsewhere.

X is far from the only example. In fact, the list gets longer every day. In 2019, a Facebook API exposed the data of millions of users because it granted overly-generous permissions to third party developers. In 2021, attackers scraped public data from a LinkedIn API, which exposed 700 million user profiles to be sold on dark web marketplaces. In 2023, one of the world’s largest Telecom operators—T-Mobile—suffered another API breach which allowed attackers to harvest the account details, SSN numbers, ID numbers and more of millions of customers, all because the particular API lacked proper authentication controls.

The problem

The reality is that API attacks and breaches are happening all the time. That’s partly due to failures on the part of owners, but it's more about the nature of the API in enterprise computing. The reality is that an enterprise could maintain hundreds or thousands of APIs at any one time to manage the needs of its partners and users. Much like cloud instances, they are extremely easy to spin up and often propagate without control or oversight. That also means they’re easy to misconfigure and often allow access to too many for too much. Any technology that does that is a great opportunity for an attacker, and we know threats don’t sleep.

APIs are prevalent, and their configurations and permissions can change over the course of the day. These can easily be exploited by an attacker with little more than a good eye and enough patience.

This wouldn’t be as much of a headache if API’s didn’t connect to such critical resources. By their very nature, APIs are meant to offer a high speed route to important data and information to other parties. These are meant to be legitimate third parties and partners, but If they aren’t configured or secured correctly—as is often the case—they merely present opportunities to steal information. APIs have become a dream target because of what they offer third parties and attackers alike: easy access to valuable data.

Mitigating API risks

It might be impossible to shut down every one, but a sensible approach would be to approach the question of APIs through the lens of risk.

First, organisations must establish a system to oversee API usage. They can’t be treated as an unalloyed good used by anyone for any purpose. Instead, their propagation has to be both controlled and overseen with a keen eye focused on the access permissions they hand out to third parties.

To enable their secure use without becoming obtrusive to broader operations, APIs have to be tightly integrated into the software development lifecycle (SDLC) and the broader application security process. That means building automated API security testing into the development pipeline in which they’re defined and modified, enabling them to be scanned continuously and as changes are made, whatever the frequency. Ideally, this would also mean that API vulnerability scanning is integrated into existing development toolchains so that it can be streamlined into workflows which developers are already familiar with, and can offer clear and actionable tickets to remediate in the same way they would any other bug.

Dynamic application security testing (DAST) is a vital way to test APIs, offering a view of how APIs are actually accessed or attacked in real life and thus address issues like injection vulnerabilities, insecure data transmission, and authentication issues. In doing so, it can test APIs while they’re live without disrupting normal operation. Given the speed at which APIs can change, testing them has to be a continuous activity and that can only really be achieved with automation and integration into continuous integration/continuous development (CI/CD) pipelines so that testing continues throughout the development lifecycle. Plus, these can be tested against a variety of standards, regulations, and industry yardsticks such as the OWASP API Security Top 10 to maintain coverage.

You can either be on the train of innovation or in front of it. APIs are a core feature of modern IT and a near-requirement to maintain competitiveness, not to mention a technology which provides incredible capabilities to those that wield it. They can’t simply be shut down or abandoned, as some security-minded people might wish to do. There is no silver bullet to whisk away all the risks associated with API proliferation. Instead, that risk has to be accommodated, and application security measures have to be in place to control, oversee and manage that risk from the moment an interface is defined to its retirement, keeping pace with APIs as they change.