API Security

With organizations pushing forward various digital transformation initiatives, the number of application programming interfaces (APIs) is on the rise, meaning that API security, sometimes referred to as web API security, is a topic of increasing urgency.

What is an API and what does it do?

An API is a set of definitions, routines, protocols, and tools for building and integrating software applications. APIs are software intermediaries that let applications communicate with one another and work together. APIs specify how software components interact together, letting one product or service communicate with others.

Using APIs greatly speeds up the application development process, which is highly desirable in the current development environment. For example, 68% of CEOs demand that their developers and security teams not do anything to slow the business down. APIs let programmers integrate functionality from external services, rather than having to build all those functions themselves.

As OWASP notes, APIs are a foundational element of innovation in today’s application-driven world. Banks, retailers, transportation systems, the Internet of Things (IoT), self-driving vehicles, and other vertical sectors and devices—all of these depend on APIs. APIs are essential to modern mobile, Software-as-a-Service (SaaS), and web applications.

Every application needs at least one API, and many have hundreds or thousands. APIs come in different forms: some are private (for internal use only), some are partnered (shared with specific partners), and some are public (allowing third parties to interact with the API). As noted below, while all APIs pose a security risk, public ones are of particular concern when it comes to API security. 

Growth in APIs and their complexity

Software developers have used APIs for more than 20 years, but the last 10 years have seen a dramatic upsurge in API adoption. A recent report finds that 59% of organizations began developing APIs only within the last five years. The main reasons organizations cite for developing APIs include facilitating interoperation between internal systems, tools, and teams (60%) and accelerating development time (54%).

The number of APIs is greatly increasing because there are now more applications and more interconnectivity between applications. Since APIs enable applications to interact, this has led to an increase in APIs and their sophistication.

One major driver of these changes is the digital transformation initiatives most businesses have launched. Customer-, partner-, and employee-facing applications are major drivers of these changes. Organizations use modern software development life cycles (SDLC), powered by Agile and DevOps, to accelerate business models, as well as to offer better customer experiences, access new revenue opportunities, and maximize operational efficiencies.

The increase is also driven by such events as the development of the IoT, the advent of big data, and the rise of artificial intelligence (AI) that require APIs to connect with applications and data stores. APIs, thus, despite being legacy technology, now connect more different kinds of programs and have also increased in complexity, leading to a variety of API protection and security issues.

OWASP notes that APIs exist in customer-facing, partner-facing, and internal applications, and that, by their very nature, APIs expose application logic and sensitive data, such as personally identifiable information (PII).

API security threats

As the number of APIs increase, so do the number of potentially exploitable vulnerabilities, giving attackers access to data such as intellectual property (IP) and customers’ PII. Indeed, Gartner predicts that APIs will soon be the most targeted attack vector. Therefore, API protection and security is critical.

A heightened API security threat environment

As the number of APIs and their exploitable vulnerabilities increase, the threat landscape has become more advanced. Bad actors are no longer primarily individual hackers operating from their parents’ basements. A recent Verizon Data Breach Investigations Report (DBIR) finds that nearly 60% of cyber criminals are organized crime and another 15% are nation-state actors.

As cyber criminals gain greater sophistication and organization, they acquire a range of technological capabilities that were unavailable to them before—from polymorphic and metamorphic malware to the use of botnets and AI that enable them to further weaponize their attacks. The growth of the dark web, including Malware-as-a-Service (MaaS), also empowers cyber criminals to instigate advanced application attacks. All of this translates into a more insecure environment and a need for API security.

API security is a challenge to developers

API security is vital because APIs serve as gateways or entryways into an application, and thus represent an appealing target for bad actors. Meanwhile, developers working with APIs focus on a narrow set of services, trying to make that feature set as robust as possible. Thus, they tend to think inside the box. Now, however, front ends and back ends connect to a hodgepodge of components, and it is attackers who have the advantage of thinking outside the box, looking for how a flaw in API security can be exploited.

Developers and security teams charged in API protection must understand how many APIs are publicly accessible. For example, out of a company’s 500 APIs, only 100 might be publicly accessible. Many applications or platforms, such as the Java platform, have a huge number of APIs that can be exploited in various ways.

One of the worst kinds of API security threats arises when a public-facing API gains access to a private API working behind the scenes. As a result, it uses that private API connection to gain access to multiple other private APIs, which creates a snowball effect.

An example of this API security breach is the notorious 2017 data breach at the credit bureau Equifax, which exposed the credit information of millions of people. The breach was caused by exploiting an API vulnerability—one involving a public API whose information was flowing into one of Equifax’s private APIs.

Why legacy AppSec approaches like SAST and DAST are inadequate for API protection and security

Traditional software defenses like static application security testing (SAST) and dynamic application security testing (DAST or black-box testing) struggle with API protection. They produce too many false positives and false negatives that must be hunted down. For instance, current research shows that more than a quarter of API security alerts are false positives. Traditional AppSec (application security) using SAST and DAST testing tools is also painfully slow because these tools infer vulnerabilities by building and scanning hypothetical models of source-code repositories, rather than actual ones. Further, SAST and DAST only yield a snapshot in time, rather than offering continuous API security.

Developers try to use a variety of tools to compensate for the API protection failings of SAST and DAST, but the very variety of these approaches creates a “tool swamp”—a situation where running all these various security tools and protocols becomes too burdensome for developers. It also creates a situation where different application testing tools are employed by different users in their own silos. The process drains staff resources and requires manual remediation. Hence, it makes sense that a Postman State of the API Report found a great discrepancy between how developers and testers spent their time and how they felt they should spend their time—manual testing and debugging consumed far more time than desired.

Security instrumentation is needed for API security

Forrester notes that application weaknesses and software vulnerabilities remain the most common openings used by external attackers and warns organizations against complacency in their application security efforts. The report from Forrester urges organizations to focus on performing security testing early in software development and the importance of automating remediation of vulnerabilities. There are now ways to address both of these concerns.

One part of the answer is to move from SAST and DAST to a different form of testing—interactive application security testing (IAST). IAST is not prone to the false positives that plague SAST and DAST because it only identifies vulnerabilities that can be exercised in an application. In addition, rather than taking a snapshot of a point in time, IAST offers continuous security coverage while developers write code.

IAST also answers the need for automating remediation by using deep security instrumentation, embedding sensors within applications so they can protect themselves from threats in real time. Security instrumentation sensors that reside inside applications can proactively reveal vulnerabilities, prevent data breaches, and secure the entire enterprise from development, through operations, to production. Using security instrumentation means that security is built into the same native tools that developers use to write and test software, and it allows security to remain with the application into production.

Instrumentation also uses route intelligence capabilities to solve security problems. Route intelligence enumerates the attack surfaces of an application. Instead of testing and re-testing lines of code, route intelligence maps URLs to code paths and informs developers and security professionals on how the application is accessed and whether they have actually tested each route. It then maps vulnerabilities to routes, letting teams know the level of authorization per route and the accessibility of any vulnerabilities. Thus, route intelligence can expose all of the different entry points into applications—including APIs—without additional specialized testing to capture vulnerabilities.

In a world where application security risks, and particularly risks to APIs, are continuing to increase, it only makes sense to abandon out-of-date legacy security practices and move forward with the most effective API security option.