What is API security, and why should you care? 

According to Forrester, Improving application security is “the top priority for global security decision-makers in the coming year,” with 21 percent “set to prioritize it as a tactical initiative.” And when you’re talking about AppSec, a major focus needs to be on Application Programming Interfaces (APIs): the chunks of software that enable apps to work together. 

APIs run the world

The world runs on a swarm of applications that need to talk to each other as they run our finances, healthcare, government, elections, military, social life and more. Those apps, in turn, rely on APIs to be their intermediaries for almost everything.

Each app can depend on multiple APIs, and as apps proliferate, so too do those smaller pieces of software. What starts as one request to one server turns into dozens or hundreds of requests to dozens or hundreds of APIs spread across a variety of environments. 

And make no mistake: APIs are everywhere.  

The modern web application is a conglomeration of interconnected APIs, microservices, web apps, frameworks, libraries and serverless functions spread across multiple cloud and on-premise environments. 

What uses APIs?  Mobile apps, awesome JavaScript browser interfaces and rich clients, for starters. Take Netflix: It runs over 1,000 microservices, each managing a separate part of the enterprise, including user management, billing, subscription management, video transcoding, personalized recommendations and more.  APIs are used throughout myriad industries, including retail, transportation and the Internet of Things (IoT), where they show up in autonomous vehicles, smart cities and baby monitors, for example. 

That means that instead of just having to protect one app from malicious actors, you have to protect hundreds of small web apps — i.e., APIs — plus the data they access and transport. 

The growing ubiquity of APIs, as well as the physical spread of the distributed infrastructure locations where they’re deployed, is known as API sprawl. That sprawl, unfortunately, presents an ever-expanding attack surface to attackers, given that APIs are just as susceptible to attack as traditional web applications. 

Anyone can easily intercept and modify the HTTP traffic being sent between the mobile banking application on their phone and their bank’s mobile APIs. Once you reverse-engineer the service API, malicious actors can try to hijack other users’ accounts, find injection vulnerabilities, access other users' data and launch other common attacks.  

Recent estimates put the total number of public and private APIs in use as approaching a massive 200 million, as APIs become ever more pivotal in the global digital economy.

TL;DR: You really need great security for your APIs.  

 Why is it important to secure APIs?  

Trouble comes from the fact that many APIs are exposed not just internally, but also externally, to customers and partners. 

Unsecured APIs have led to major data breaches, including, to name just a few, LinkedIn’s 2021 breach, Parler’s 2021 “Hacktivist” breach and Clubhouse’s 2020 breach. Though the technical API flaws behind the LinkedIn breach still aren’t clear, signs point to issue No. 3 on the OWASP API Top 10, where the API may have exposed more object properties publicly than needed.

As for Parler and Clubhouse, both had APIs that could be exploited to download all their user data, whether it’s because, in the case of Parler, there was an unprotected API that had no limits placed on it or, in the case of Clubhouse, that the service didn’t technically enforce scraping limits. Both are examples of OWASP Top 10 API 4: Lack of Resources & Rate Limiting. 

Unfortunately, just as APIs have given us ever-richer client interfaces, they’ve become some of attackers’ favorite targets.

You can see why: All too often, APIs are weak spots. As of 2017, Gartner Research was predicting that 90 percent of web-enabled applications would be more exposed to attack by API weaknesses than via the user interface — up from 40 percent of apps in 2019. Indeed, within two years, Gartner predicted, APIs would be the most commonly targeted attack vector in the enterprise. More recently, in December 2021, Gartner predicted that by 2025, “less than 50% of enterprise APIs will be managed, as explosive growth in APIs surpasses the capabilities of API management tools.”

Sorry: Your AppSec doesn’t work on APIs!

You may well think that our current security tools are appropriate for APIs, but alas, they aren’t. Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) were designed for web applications from the early 2000s, and they haven’t advanced much since then. While APIs are just as hackable as traditional web apps, many are surprised to find that securing APIs isn’t the same as application security.

Generally, the client-side of these applications isn’t particularly risky, but, given that their APIs protect all the data for all the users, we desperately need a way to verify their security. There are plenty of scanning tools for finding vulnerabilities in web applications, but even though they talk HTTP, APIs work differently.

Cases in point:

Nope on DAST.  Many products claiming to be focused on API Security rely on dynamic scanning.  DAST scanners send HTTP requests containing attacks and check the responses to see if the attack worked. Sometimes, there’s clear evidence of a vulnerability in the HTTP response, such as a cross-site script in the HTML. But usually, the evidence is less clear, such as when you send a SQL injection attack and the response is a 500 error. Was there a SQL injection? Or did the application simply break?

This problem is exacerbated when testing API security. The scanning tool can’t invoke the API because there’s no way for it to know how to generate well-formed requests. Even if you have the API spec in Swagger or similar formats, it’s still exceptionally difficult to provide the right data to automatically invoke an API and make the code run properly. The result: Your DAST will end up missing many serious vulnerabilities. Even worse, many APIs use custom, non-standard protocols and data structures. Google Web Toolkit (GWT) apps, for example, have their own custom syntax and can’t be scanned without a custom scanner.

Standalone SAST doesn’t cut it. Fortunately, there’s a way to get your head above water when it comes to this deluge of security problem-plagued APIs, but the answer doesn’t lie in a scanner-only approach to verify the security of apps that publish APIs. 

Scanners tend to give you a false sense of security that comes from attempting to scan the unscannable, as they try to piece together how the app runs and how the data flows work. These tools often miss vulnerabilities and report false positives because they simply can’t trace the complex maze of program execution, third-party library use, state management, route management, object mapping, validation, encoding and other common API patterns. The scan runs and reports nothing, leaving you in the dark about whether you’re actually secure or whether the tool simply didn’t understand what it found. 

Instead, you need to focus on APIs that are actually running. 

What we really need

In sum, tools in the market today take disparate approaches, failing to address the requirements of what an API needs in a single platform. What dev teams need to ease their burden:

• Runtime IAST testing,
• RASP protection to block zero-day attacks and
• SCA to scan all code from third parties.

Stay tuned for more on this subject: We’ll be taking a look at the state of API security tools in a future post. 

Security instrumentation to the rescue

Fortunately, there’s a different way to verify APIs and other services: instrumentation. The term simply means adding some monitoring code to your application at runtime, exactly the same way Application Performance Monitoring tools do. This technique is often used to add logging or timing code to a service or application.

Security instrumentation embeds sensors within applications so they can identify vulnerabilities and protect themselves from the most sophisticated exploits in real time. Being in the code can potentially uncover vulnerabilities, prevent data breaches and secure the entire enterprise — from development to operations to production — largely without human intervention.

Security instrumentation solves the problems that prevent DAST and SAST from working on APIs for a few reasons: 

• You don’t have to attack the application to find vulnerabilities. Nor do you have to teach a security tool how to invoke complex APIs. Instead, you can simply watch how normal application behavior works and recognize vulnerable application behavior.
• You don’t have to build a complex model of the application. Instead, you can directly analyze the actual running application itself. This allows for the tracing of control and data flow of complex API frameworks as they execute, enabling highly accurate insight into the security-critical details that reveal vulnerabilities.

Instrumentation has revolutionized web analytics, performance management and other software-related disciplines. Commercial products have allowed performance engineering to evolve from something that only experts could do with their expert tools, to something everyone can do for themselves. 

This is the transformation we desperately need to scale application security. 

We can use security instrumentation to make application security better, faster and, most importantly, relevant to the types of modern applications that developers are building today, including APIs.