The Application Protection Research Series is an ongoing project at F5 Labs that provides an overarching view of the application security landscape. While detailed analyses of specific attacks are critical for defenders to adapt to emerging techniques, it is easy to overemphasize tactics over strategy if those kinds of analyses are the only thing we consume. In contrast, this research is particularly focused on longer timeframes for analysis, since time is an indispensable component in calculating risk. This perspective also allows us to escape the hype around the vulnerability, APT, or exploit of the week. Where we can, we use quantitative methods to be as objective as possible. Where necessary, we read between the lines of both data and human behavior to tease out the crux of application security in the present moment.

In 2019, this project began to focus on the subject of application architecture. This focus came about for two reasons. The first is that applications have changed. Specifically, applications have moved toward an increasingly distributed and decentralized model. The result is a growing emphasis on connecting disparate services over the web as opposed to creating large, multifunctional monoliths. The fact that this movement has been gradual, and the sum of a number of smaller, more evolutionary developments, should not obscure the magnitude of this transformation.

The second reason for our new focus is the fact that attackers have successfully adapted to take advantage of these changes, and in general have done so more quickly than defenders have. The evidence for this successful adaptation lies in both the number of significant successful attacks over the last few years and the characteristics of these attacks. Even though attack details vary significantly, the overarching pattern is that these architectural shifts are causing organizational breaches in ways that should have been easily avoidable. This holds true across the spectrum of expected competency and maturity for defenders. It’s not just small startups that can’t afford to prioritize security that are being compromised through emerging architectures. Some big players in our industry are finding out too late that their data are hanging out all over the place.

Application programming interfaces, or APIs, are the most prominent and grave example of an architectural change driving actualized risk. As a result, we are devoting a big part of our 2020 Application Protection Research Series to understanding the changing relationship between APIs and application security. To be clear, we want to emphasize early on that APIs are not inherently more or less risky, and they have an enormous range of advantages in the present business environment. Rather, we argue they represent a transferal of risk away from traditional security foci and into new realms, and until we understand that transferal better, APIs will continue to be a source of security breaches for organizations. Our goal is not to scare people away but to provide options and guidelines for application owners to maximize the benefit and minimize the risk of these architectures. This article is the first in a series that will explore the topic from a number of angles, but we will begin here with the big picture surrounding API incidents.

API security may seem like old news, and a prodigious body of literature already exists on the subject. Some of it is even from F5 Labs, like our piece on what APIs are and why they matter as well as the article on API breaches for the 2019 Application Protection Report. Some people are also ready to take your money to fix your API problems. The market for API management or mediation solutions is established and growing. What can we add to this discussion?

What we want to emphasize, in addition to merely echoing existing calls to take API security seriously, is that the architectural shift APIs represent has broad and lasting implications for application security and ultimately for the balance of risk and reward for putting services on the web. Taken as an individual component, the API is an evolutionary development—a slightly different angle on the same basic value proposition of web applications. Taken in context with other architectural changes as well as economic forces presently shaping the Internet, however, APIs represent more of a break with the past than continuity. Seeing these changes as discontinuous is important in recognizing that API security, and the implications it has for application security, is not a one-time project. API security will define the next phase in application security; this is the battlefield on which the next few years will be fought.

Having said that, to establish a baseline, we will begin by presenting some general trends in API breaches and incidents over the last few years. Then we’ll unpack what we can conclude from these data before establishing deeper questions that we’ll be investigating over the course of 2020. But first, a note on our sources for this project.

Sources and Methods

The API incident data we use here comes from a collection of open-source reports on API incidents, including both confirmed breaches by malicious attackers and vulnerability discoveries by security researchers. We only selected incidents in which data were confirmed exposed or breached, as opposed to vulnerabilities whose exploitation depended on preconditions that made them largely theoretical. The dataset we used for this article lists 67 known incidents from 2018 to July 2020.

One interesting facet of this dataset is that more than 75 percent of the incidents were reported by researchers as opposed to organizations that were breached by malicious attackers. Since we know that most organizations who are notified by security researchers will eventually publish their vulnerabilities, (to keep the researcher placated if for no other reason), we can assume that our data contain the bulk of those incidents that were responsibly disclosed. However, given the difficulty of identifying intrusions, and the enduring lag in time between intrusion and discovery, we feel that this dataset almost certainly under-reports the number of malicious API incidents. As successful attacks are discovered, the ramifications of our current Wild West period of API deployment will doubtless reverberate into the future.

Findings

The first thing that stands out about the data is the growing number of events. We observed nine incidents in 2018, 35 in 2019, and 25 so far in the first half of 2020. At this rate, the number of publicly reported API incidents will approach 50 by the end of 2020 (see Figure 1).