In the wake of the SolarWinds attack, an executive order advocated mandatory software bills of material (SBOMs) to increase transparency into the potentially vulnerability-laden components tucked into applications. This government move signified that we’re on the cusp of AppSec — including application programming interfaces (API) security — becoming transparent.

We are, in fact, on the brink of a market transformation — one wherein application security will hopefully become visible and transparent to consumers. Transparency helps to ensure that consumers can make informed decisions about the software they trust everything important in their lives to.

But apps are only as secure as each one of the scores of APIs they interact with. That makes it essential to understand not only how to secure applications, but also how to secure the APIs that enable them to run.

But first, what is API security and why is it important?

According to Forrester, improving application security is “the top priority for global security decision-makers in the coming year,” with 21% “set to prioritize it as a tactical initiative.” A major focus must be on APIs: the software apps use to talk to each other.

When it comes to securing APIs, the 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 LinkedIn’s 2021 breach, Parler’s 2021 “Hacktivist” breach and Clubhouse’s 2020 breach. All three, plus many more, have been potentially or definitively attributed to API flaws found on the OWASP API Top 10. That list includes APIs that publicly expose more object properties than needed, as well as APIs that can be exploited to download all user data — whether it’s via gaps in defenses, vulnerabilities in API code, or vulnerabilities in open source libraries.

Just as APIs have given us ever-richer client interfaces, they’ve become some of attackers’ favorite targets due to flaws such as these. 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!

APIs are just as hackable as traditional web apps. However, securing APIs isn’t the same as application security. Traditional appsec tools aren’t appropriate for APIs. Static Analysis Security Testing (SAST) and Dynamic Analysis Security Testing (DAST) were designed for web applications from the early 2000s, and they haven’t advanced much since then.

APIs communicate using HTTP with a payload containing XML, JSON, serialized objects, or custom data. The complexity of the network traffic and the software frameworks used creates problems for traditional tools.  For example:

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.

SAST. Scanners tend to give you a false sense of security as they try to piece together how the app runs and how the data flows work. These tools both 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.

In sum, tools in the market today fail to address the requirements of what an API needs in a single platform. What dev teams need instead:

• API Testing from within (IAST),
• API Library Analysis to scan all code from third parties (SCA), and
• API Runtime Protection to prevent vulnerabilities from being exploited (RASP)

Security instrumentation to the rescue

Fortunately, there’s a different way to verify APIs and other services: instrumentation. Security instrumentation embeds sensors within applications so they can detect vulnerabilities with full context and protect against the most sophisticated exploits in real time. Being inside the running application, like a profiler, provides the context required for extremely high accuracy.

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. Performance engineering has evolved 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 security for both applications and the APIs they run on.

— Jeff Williams, co-founder and CTO of Contrast Security

Bio: Jeff brings more than 20 years of security leadership experience as Co-Founder and Chief Technology Officer of Contrast. Previously, Jeff was Co-Founder and Chief Executive Officer of Aspect Security, a successful and innovative application security consulting company acquired by EY. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for eight years and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many other widely adopted free and open projects. Jeff has a BA from the University of Virginia, an MA from George Mason, and a JD from Georgetown.