A robust API security strategy starts with development but needs a dedicated focus on API runtime security to fully defend this ever-growing and changing attack surface. Shift left has become increasingly important to build security into the development process. But for API protection, shift left leaves several security gaps.

Organizations need runtime protection to protect APIs already running within their systems. If an organization relies on shift-left capabilities alone, it puts itself at risk. This is particularly true with APIs.

There’s no doubt that shift-left capabilities provide value to organizations. By adopting these practices, companies can strengthen developers’ understanding and support for secure coding practices. Shift left can also help drive a more security-driven strategy throughout the entire organization.

However, to fully secure APIs, organizations must also apply runtime protection. There are five main reasons why shift left and runtime protection can’t be an ‘either-or’ for API security:

• Testing tools can’t spot business logic gaps.
• Runtime security protects critical assets that are already running.
• APIs built for internal use often get pulled into external applications.
• Pre-packaged APIs can’t be changed.
• Perfectly-written APIs can be abused.

1. Testing Tools Miss Business Logic Vulnerabilities

APIs are essentially built upon business logic and underlying application logic. The most significant security risks lie in business logic flaws, which are extremely difficult to flush out in a siloed manner with code analysis and traditional SAST and DAST scanning. As a result, while automated pre-production security testing provides decent coverage for identifying known vulnerabilities, such as SQL Injection, for example, they lack the business function and business logic context to adequately and effectively flush out logic-based vulnerabilities in APIs.

Business logic attacks — rather than known security threats — present the biggest risk for API-driven businesses. Most of the OWASP API Security Top 10 vulnerabilities derive from business logic flaws, which presents a huge problem for relying on shift left to protect your APIs. In application logic attacks, hackers poke and prod — over and over again — to uncover holes in coded application logic. They’re seeking areas for potential exploitation, such as gaining unauthorized access to data or functionality within the API, or weaknesses in the API to launch application denial-of-service (DoS) attacks.

To spot business logic flaws in APIs, you need to see the API’s endpoints in action and obtain a deep understanding of the functional purpose of each of the endpoints, as well as understand the behavioral characteristics of each parameter and element in use by those endpoints. The challenge is that a single API endpoint alone could have thousands of possible permutations of business and underlying application logic that would need to be properly vetted and exercised in order to understand if the endpoint is capable of performing any negative behaviors.

If you need more evidence, consider the API security incidents that have been generated by business logic flaws, including those at Experian, Facebook, LinkedIn, and Parler, among others, who all employed mature DevSecOps practices for their APIs prior to deployment. In addition, pre-production testing would never have discovered one of the biggest and potentially dangerous zero-day API vulnerabilities of all time, Log4j (Log4Shell).

With all of that being said, remember that you are not facing an ‘either-or’ choice. An API software development lifecycle should employ pre-production security testing methods and tooling, just like any other application lifecycles. These tools help verify many parts of an API implementation and provide significant value by weeding out well-known misconfigurations and vulnerabilities before deployment. However, it is important to also recognize that siloed automatic testing, even API-specific security testing, will not capture many API business logic-related risks, and manual negative function testing quickly becomes infeasible within a large and ever-growing API ecosystem. A proper API runtime protection is paramount as it provides organizations with a vital safety net to complement pre-production testing efforts.

2. Runtime Protects What’s Already Running

Another gap with shift-left practices is that they improve security only for your net new APIs. But most organizations have dozens or hundreds of APIs already running, and those vital conduits need protection now.

Keeping track of all the APIs running within an environment has become increasingly challenging. Outdated or “zombie” APIs and unknown “shadow APIs” represent a big source of worry for IT security leaders. Without an accurate inventory of the APIs being used across their environment, the organization places itself at risk. Just missing a single API in your inventory, not understanding what data it handles and how it is being used, and by who, means that you are potentially exposed. Proper API runtime protection casts a safety net not just on the APIs you already know about, but also offers protections for the ones you did not.

Organizations need continuous API discovery to guarantee they have proper inventorying in place to manage risk and exposure. Your inventory should be continuously and automatically updated. Manual processes no longer suffice when it comes to tracking the volumes of APIs that exist within a given environment. Finally, API discovery should do more than just let you know that an API exists. You need to understand how it is used, how frequently, and the type of data it ingests and exposes.

After you know all your APIs, you must also monitor them continuously in production. By monitoring APIs in runtime, organizations gain an understanding about normal API traffic versus abnormal traffic in their environment, allowing them to quickly spot potential abuses. With these insights, you can more quickly spot attackers that are poking around for business logic holes and weak points in your APIs to attack.

Only runtime protection, with accurate behavioral anomaly detection, can find the “low and slow” patterns of API attacks. To prevent these types of threats, organizations also need visibility over time. API abuse reconnaissance can take days, weeks, and even months.

3. Organizations Often Change Internal APIs to External APIs

Many companies will externalize APIs that were initially intended for internal consumption only. In these cases, they don’t always adhere to the typical security processes that would occur for an external API. Developers build these APIs quickly and often don’t go through any shift-left cycle.

Problems arise because these ‘internal’ APIs frequently get integrated into some type of external function in the software development lifecycle. Somehow the APIs start being used ‘outside’ as they have some business logic value that is useful in another external business function. Because these APIs have not been fully reviewed from a security standpoint, they create potential vulnerabilities. Runtime security becomes essential to quickly spot weaknesses in APIs that may have been deployed externally without the appropriate testing. Many times organizations don’t even realize that internal APIs are being used externally.

An important side note: if your organization puts the right internal processes in place, you can avoid this pitfall. All of your APIs, whether internal or external, should be put through the same developer governance, including documentation, and vetted the same way. With the rapid cadence of digital transformation projects, you never know where an API may be used over time.

4. Pre-Packaged APIs Can’t Be Changed

Organizations don’t always write their own APIs. Many organizations, such as smaller banks or credit unions, will use packaged systems, both in the cloud and on-premise, to enable capabilities such as mobile banking and other online services. Because they didn’t write the code for these applications, they exert no influence on their development. In deploying packaged API systems, organizations must trust that the developer followed API security best practices.

However, at the end of the day, the fact that you didn’t write the code doesn’t give you a ‘get-out-of-jail-free’ card. You’re still responsible for the availability of your systems and protecting your customers’ sensitive and private information, even if you didn’t write the API.

Since you can’t change pre-packaged code, you need to secure the packaged product. Runtime protection with continuous visibility to monitor deployed API services can quickly spot attacks on potential vulnerabilities and abusive activity.

5. Even Perfectly-Written APIs Can Be Abused

Finally, many API security incidents occur by hackers using the API as it was designed. For example, attackers frequently reverse engineer mobile applications to see if goodies, such as API keys, are accessible in any way. Once obtained, an attacker will use the keys to access and exercise the “protected” APIs. Perpetrators will often use social engineering techniques to obtain an authorized user’s keys or credentials to enable exploitation.

The recent Twitter API key and Peloton incidents provide examples of abusing an API as designed for data exfiltration and unauthorized access. A legitimate usage of an API can allow attackers to gain access to restricted data. This vulnerability can be further explained in the OWASP API3: Excessive Data Exposure.

Runtime protection raises a red flag to help organizations determine intent and detect malicious users that could actually be using the API correctly functionally. With continuous runtime insights, you can baseline and track API access per endpoint and per user to spot overconsumption of data that does not reflect normal usage. This differs from the poking and prodding of a business logic attack. The API didn’t have a business logic gap — instead, a bad actor has figured out a clever way to use the API in a nefarious way to obtain valuable data, or find “soft spots” in API endpoints to create a targeted and coordinated application-level DoS attack.

Final Thoughts: Runtime Security Reduces Your API Risks

Shift-left measures help organizations become more strategic about security and improve secure coding practices in development. However, relying on shift-left methodologies for API security is a risky proposition. This is due to security issues in production APIs being at an all-time high, and the lack of business logic context in shift-left security tools. Bad actors continue to use hard-to-detect methods to target APIs for abuse. Many of these attacks cannot be detected in pre-production testing, including business logic attacks and more subtle attacks that may be using an API as it was designed to be used but for malicious intent.

In addition, there are non-applicable shift-left situations. For example, if your organization uses pre-packaged APIs, you can’t change the code. You must instead protect the package in runtime to arm your data and services. Or, you may have a situation where shift-left testing wasn’t applied because the API was only supposed to be used internally. Or, perhaps a shadow API skirted the typical governance model altogether. Companies need to ensure that developers adhere to appropriate shift-left testing for all APIs — external or not.

Most people would choose a safety net in situations of high risk. Even if you have a single API that is vulnerable in some way to abuse, the effects can be dire. By using shift-left capabilities and runtime protection in tandem, you maximize the protection of your APIs and your organization’s most vital assets.