Assessing API Security Risks, Plotting a Solution

Application programming interfaces (APIs) are increasingly opening paths to vulnerabilities further down in application architectures. But legacy security testing approaches and firewalls are an inefficient and ineffective approach to securing APIs, as they lack the context of how the API is implemented. The ideal approach to API security involves integrated technology that continuously protects the API and its implementation at all stages of the software development life cycle (SDLC), thus eliminating the need for specialized security staff and endless alert monitoring. 

Application programming interfaces (APIs) are everywhere, serving as the critical intermediaries between applications in our increasingly connected digital world. Public APIs like REST, gRPC, and Open API-driven implementations are a prime target for attacks.

In fact, Gartner estimates that APIs will soon become the most commonly targeted vulnerability within organizations. Consistent with this estimate, the 2020 Verizon Data Breach Investigations Report (DBIR) notes that 43% of data breaches are tied to web application vulnerabilities. The costs of a breach are all too well known, with breaches potentially resulting in stolen intellectual property, operational disruptions, privacy violations, and reputational harm. These damages often result in substantial short-term and long-term financial losses.

Given that the average organization has hundreds or even thousands of APIs, API security is a critical need for companies.

Legacy Application Security Testing Is Ineffective for API Security

Organizations increasingly recognize the need to “shift left”—that is, to focus on security during the earliest stages of software development, including when developing APIs.

But the most common approaches to this pre-release security testing—static application security testing (SAST) and dynamic application security testing (DAST)—are burdensome and ineffective. Penetration testing pushes application security too far to the right, which consumes valuable development time spent in remediation. Indeed, research also shows that the further right vulnerability fixes are pushed in development cycles, the higher the cost in terms of time and resource allocation.

SAST and DAST Defined

SAST involves looking at the underlying code; those carrying out SAST do not actually test the application while running. In contrast, DAST involves testing for vulnerabilities in an application’s running state, but it does not understand how the API fulfills its contract or how it uses the data coming in.

SAST and DAST: Two Flawed Approaches to API Security

Both SAST and DAST have significant drawbacks when it comes to API security. SAST involves time-consuming, line-by-line code checking that often generates many false-positive security alerts. Triaging and diagnosing each security alert to determine whether it is valid can burn significant cycles for both development and security teams. In addition, SAST tools focus on known threats, which leaves the code vulnerable to unknown threats (so-called zero-day threats) that may arise. Finally, third-party frameworks and libraries most often appear in bytecode/binary form where source code is not available—namely, code analysis does not function when the code is not present. With the unique ways in which libraries function, even custom rules do not keep up with forward- and backward-compatibility changes in the libraries. These encompass class name changes, inversion of control, and annotation-based programs. The result is that by the time a SAST tool supports a framework, the API vulnerability is already legacy.

DAST is problematic because it cannot invoke the API due to the fact that there is no way for it to know how to generate well-formed requests. And even if the request is known, it is exceptionally difficult for DAST to provide the right data to automatically invoke the API correctly. As a result, many applications do not execute normal behaviors during a DAST scan with its Web 1.0 1990s style page-parameter requests.

Here, the assurance DAST provides is only as good as the tests. If DAST fails to sufficiently challenge the application, application owners are blind to vulnerabilities. In addition, it is hard to create tests for APIs because many of them have custom operations and nonstandard protocols that are not encompassed by DAST tools. Even with a simple case of a RESTful path parameter, DAST scans never know where the endpoint ends and which parts are parameters. The best they can do is become good “guessers.”

Both SAST and DAST involve considerable time and wasted efforts, while introducing the potential for human error without providing real assurance about the security of an application. Moreover, each approach is particularly problematic in the context of API security. Indeed, when it comes to API security, SAST and DAST are not so much a shift left as a shift up in aggravation and uncertainty.

Existing Security Measures Are Inadequate for Protecting Running APIs

While SAST and DAST are ineffective in predicting how secure an API will be once it is released into production, existing measures designed to protect the API once it is actually running, such as web application firewalls (WAFs) and other perimeter-based security gates, also fall short. These security gates cannot defend against unknown threats or zero-day attacks. In addition, WAFs often generate alerts that require manual intervention by security operations (SecOps) staff to determine if they actually reveal a vulnerability that poses a risk or one that is not a risk.

As part of this process, more than one-third of application security alerts end up being false positives. The end result are API security alerts that require too much time for remediation and wasted time and resources diagnosing and triaging alerts that turn out to be false positives.

Devising a Better Way to Protect APIs

If SAST, DAST, and WAFs are inadequate tools for protecting APIs, then what would be the attributes of an effective approach to API security? 

As each of these approach application security from outside of the software, the answer is that application security must derive from inside the running software. Just as software instrumentation has proven itself to be the answer for application performance monitoring (APM), it is the answer for application security—for both development and production.

Snapshot Analysis vs. Continuous Monitoring and Protection

There is one additional negative derivate of SAST and DAST: They are a point-in-time scanning test. SAST looks at the state of the underlying code for a particular point in time, even though the code often will likely be adjusted after release. Similarly, DAST is a point-in-time stress test on a running application. But passing a SAST or DAST test does not mean that an application is invulnerable to all future threats.

Instead of providing application security that derives point-in-time snapshots of an API’s security, application security needs to provide continuous monitoring throughout the SDLC—from the earliest stages of development, to quality assurance and testing, to production.

Achieving a Level of API Security That Is Continuous

To further elucidate the limitations of legacy approaches to API security and envision a solution to API security, it might help to compare these concepts to well-understood ideas in medicine.

DAST and SAST are like visibility into the past: somewhat helpful but far outmatched by continuous monitoring enabled by interactive application security testing (IAST). Consider diabetic patients where diet causes significant changes in a patient’s glucose levels. Knowing that the patient ate bread or had a snack three weeks ago, or a point-in-time blood test from months prior, does not inform us of how much insulin the patient needs right now. Like the continuous monitoring of IAST, many diabetics have reported life-changing benefits from continuous glucose monitoring that analyzes and delivers the right treatment at the right time. While the monitor does not prevent spikes or drops, it engages the patient to better analyze what is happening while giving them near-immediate feedback.

What is really needed for API security is to understand and mimic the reason why this is successful—namely, how can API security provide continuous feedback and offer a life-changing result.

How API Security Instrumentation Works

Software instrumentation is now widely adopted across applications in development and production. Sensors or agents are embedded within an API from the start of coding and continue to protect the API once it is released into production. Major software platforms have supported instrumentation for decades, with .NET supporting Profiling since 2000, Java since JDK 1.5 instrumentation in 2004, and languages like Python, Ruby, and Node following similar timelines.

In the case of security instrumentation, the agent automatically monitors the coding for known and unknown issues by monitoring the application in runtime during the initial application startup. When a vulnerability is detected, developers are alerted when it was introduced into the application—whether via custom code or open-source frameworks and libraries. Unlike code analysis, instrumentation leverages the common point that all code is designed to run. Upon releasing the API into production, the same agent detects and blocks attacks on vulnerabilities in real time.

The agent observes what data and requests an API accepts and its runtime usage, checking data packages and runtime behavior for vulnerabilities against cyberattacks. When an attempt to exploit a vulnerability is detected, the attack is blocked by shutting down the API execution route. This inside-out software instrumentation approach delivers observability that WAFs and other perimeter security solutions cannot achieve. Specifically, rather than simply watching what comes in, security instrumentation observes to see what comes in and also what happens once it is inside the application.

Connecting the Benefits of Instrumented API Security

The benefits of security instrumentation that employs continuous detection and protection of APIs are dramatic. Some of the most significant ones include:

• API security risks are dramatically reduced as security monitoring is in real time and vulnerability remediation verification is automated and accurate.
• False negatives are virtually eliminated as application security does not rely on known signatures, as is the case with SAST and DAST, but rather analyzes software for vulnerabilities based on which routes are exercised—detecting both known and unknown vulnerabilities.
• Application security does not require significant workload capacity to run security scans and specialized security staff to manage them.
• Development teams no longer need to slow development cycles due to false vulnerability alerts and time-consuming security scans.
• SecOps teams no longer need to spend valuable time chasing false positives identified in production runtime.

Mapping Out Your API Security Requirements

API security is certain to grow as an area of focus for application security. More applications in development and production translate into more APIs. To gain an in-depth understanding of what you should seek in API security, download a copy of our recent eBook—“How to Secure APIs at DevOps Speed.”