Modern APIs Need a Different Security Approach

Organizations leverage application programming interfaces (APIs) regularly, often without giving them much thought. The benefits APIs deliver enable companies to monetize applications in new and exciting ways, ultimately driving revenue and gaining market share from competitors. This is because APIs offer a data transfer approach that allows services within an application to talk to other applications or other services within a system. In short, APIs facilitate communication from service A to service B in a uniform way. For example, when someone shops on Amazon or signs in to their favorite social media platform, the application fetches and updates the data they are interacting with by using APIs. 

APIs, for all the good they bring, also open new attack surfaces resulting in increased vulnerabilities and exposures around a company’s data. As a result, discovering and securing APIs is a constant battle for IT teams in all industries. As highlighted in Gartner’s report, API Security: What You Need to Do to Protect Your APIs, it was estimated that last year 90% of web-enabled applications would have more surface area for attack due to exposed APIs than the user interface (UI). This was up from 40% in 2019 and ended up being a fairly accurate prediction of what happened in 2021. Furthermore, the hundreds and even thousands of new public cloud services available for building modern applications that can be accessed via APIs have made this attack surface problem far more prevalent today.

Traditional approaches to API security include enterprise API gateways and content delivery networks (CDNs). While these methods can protect against most brute force and denial-of-service (DoS) attacks, a more sophisticated and nuanced attack can breach these security measures. Traditional approaches to protecting modern cloud, mobile and web APIs are full of limitations, and more advanced approaches need to be considered. 

API Basics

To take a step back, companies typically use two types of APIs – customer-facing external APIs, often called north-south APIs, and internal APIs, referred to as east-west APIs. While the internal type can be more easily protected, it’s no surprise that external APIs are more vulnerable because they’re exposed to all public internet traffic. External developers can make requests and receive responses to these external customer-facing APIs and take advantage of an application’s data and functionality while bypassing the UI. On the other hand, internal APIs are exposed to only intra-application traffic. To illustrate, in an e-commerce application, for instance, a cart service may call a user service by leveraging an internal API during the checkout process.

External APIs are often more visible, stable and targeted at a developer audience than their internal counterparts. The biggest challenge with these customer-facing APIs is continually ensuring that this layer is secure. The open and accessible design of this type of API is so that developers outside the publisher’s organization can utilize them. The goal of external APIs is to cater to a community of technical audiences and, ultimately, increase the use of the organization’s services and data. API publishers will sometimes encourage developers to create applications that expand on the core business. 

While internal developers can call on external north-south APIs for their application development, they more commonly use internal east-west API calls between services to drive their new innovations and incremental feature development. In some cases, the ratio of internal to external APIs could be between 1:10 to 1:100. While internal APIs may or may not be accessible by developers outside the publishing organization, more of these internal APIs are becoming native in the public cloud. As a result, attack surfaces are greatly increased and can easily be exposed publicly. In addition, changes to these internal APIs are made on an ongoing basis as fast as a company’s CI/CD and DevOps practices will allow. Unfortunately, this speed of change causes more mistakes, errors and security oversights. These APIs and changes are less visible than their external API counterparts, which leaves organizations at risk of discovering vulnerabilities only after a hacker has successfully breached its private data.

All APIs can leak data, but organizations are unable to protect what they don’t know. That is why shadow APIs, or APIs used outside the control of IT, can be so detrimental. As soon as APIs are exposed on the Internet, they create an expanded attack surface for hackers to leverage for data exfiltration. We have seen some of the largest companies in the world have security exposures throughout their API service catalog, so it’s not hard to imagine that smaller companies would, as well.

Since APIs are such a ubiquitous method of passing information, API breaches are very common. These breaches are quickly becoming the most lucrative and large-scale attack surface for hackers. There are many types of data breaches, but they almost always negatively impact a company’s reputation and revenue. You just have to follow the headlines; new API breaches and vulnerabilities happen almost daily. Capital One, Microsoft, T-Mobile, Symantec, McDonald’s, Instagram, Salesforce and Venmo have all experienced major API breaches in the past few years. 

Securing APIs in Modern Applications

The DevSecOps or security team should make ongoing risk-based decisions regarding when discovered issues should be mitigated and where in the CI/CD pipeline those issues should be tested. To help prevent a security incident from occurring or escalating, automated active monitoring and protection is required. IT teams need to use tools that add this layer of automated protection and do not require humans to be involved.

Traditional approaches to API security can be helpful in reducing the attack surface, but they are too slow to keep up with the ever-evolving advanced tactics of bad actors. IT staff requires a clear and full-stack view of an application’s security to manage risk and enforce appropriate security policies. Without better telemetry and observability, every security decision will be a best guess and critical holes in API security will be missed.

Security approaches need to continually analyze cloud environments, API gateways, logs, web and mobile applications, as well as source code for changes that might result in vulnerabilities. If IT can identify the changes to their system, they can confirm that authentication, authorization, encryption, access and verification meet the standards set for the team.

Automated active protection that requires zero human intervention is the only way to realize real-time enforcement of security policies and protect against continuous attacks as they occur. A security solution should be able to automatically discover and inspect for API security vulnerabilities, while humans analyze the situational risk and prioritize the work.

Only with automated active protection will IT teams have the telemetry and observability needed to manage risk and enforce appropriate security policies. With this approach, IT will be equipped to rapidly leverage critical information and accurately identify the affected components of the system, discover the contributing factors that led to the event and protect the data when a security incident occurs.