Application programming interfaces (APIs) have become a necessary part of doing business in the digital era. Most of the interactions your customers will have with your business online rely on APIs. While your customers see a unified digital experience, hackers see a different picture. To them, APIs present a buffet of options- relatively unsecure systems that they can dine on.

When considering the security of APIs, the conversation can quickly become technical. And while a technical discussion is important, many organizations are still struggling to implement even basic API security practices. Up to 34% of organizations do not use API security at all. Luckily, there are some foundational solutions they can put in place to curb the threat. We have previously talked about one fundamental tip to improve API security which involves security teams sharing some responsibility with API teams. In this article, we will look at 6 more tips that will help improve the security posture of an organization’s APIs.

Why is API security important?

APIs are generally available on public networks making them large targets for hackers. They also often store private customer information such as Personal Identifiable Information (PII), and sometimes Personal Health Information (PHI). Companies risk financial and reputational damage should their APIs get attacked.

Massive amounts of data can be breached in API attacks. One of the most impactful attacks from 2021 involved LinkedIn’s API. In this attack 700 million users’ data (making up 90% of its user base) was breached. The data contained information on names, phone numbers, and addresses. This PII was then offered for sale on the dark web. 

Sourced from F5 Labs

There are an estimated 200 million APIs in existence and predicted to triple in the next 10 years. Due to the rate of digital transformation companies are undergoing, the incidence of APIs, and their often unchecked attack surfaces, the potential for attack is high. However, good policies and practices around APIs can significantly decrease an organization’s risk. 

Tip 1 – Use the OWASP top 10 list as a guideline, but not gospel

The OWASP top 10 provides annual guidance for the top 10 most critical web application security risks. It is considered the standard by many professionals. Anybody who is dealing with web application security should, and probably has, looked at this list. Many do more than just looking. AppSec teams early in their life sometimes use it as the end all be all of application security. OWASP themselves do not recommend this. They say, “the OWASP Top 10 2021 is a good start as a baseline for checklists and so on, but it’s not in itself sufficient.”

First let’s get into where the OWASP top 10 can help. The 10 vulnerabilities described cover a range of bases. Areas such as authentication, access control, security logging, and injection threats are discussed. These help to familiarize an AppSec team with a breadth of areas that are most vulnerable to attack. There remain however three reasons why this cannot fully be leaned on for security.

Sourced from OWASP

Vulnerabilities can extend beyond this list and new vulnerabilities can arise. Three new vulnerabilities were added in 2021 as compared to 2017. Security threats are always evolving and security teams have to be vigilant to all possible threats.

Another limitation of the list is that not all vulnerabilities are readily tested for. For example we’ll look at A04:2021- Insecure Design. OWASP says it “is a new category for 2021, with a focus on risks related to design flaws. If we genuinely want to “move left” as an industry, we need more threat modeling, secure design patterns and principles, and reference architectures. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.” These design flaws are also called “business logic flaws”. They relate to unexpected ways hackers exploit design features of the API after it is deployed. We talk in more detail about these flaws in our article on shared API responsibility.

A final thing to consider with this list is that web application security is not the exact same as API security. Vulnerabilities remain the same, but other things have to be taken into account with APIs. Which brings us to…

Tip 2 – Know the differences between web application security and API security

In many ways API security presents more challenges than traditional Web Application Security (Web AppSec). Most of the differences can boil down to APIs having a broader attack surface. For one, traditional web applications have a well protected perimeter. APIs have many endpoints, use different protocols, and tend to expand over time. This creates a perimeter with multiple entry ways that is much more difficult to protect.

As compared to Web AppSec, users of APIs are more likely to access them with something other than a web browser. Most APIs are accessed by mobile or native applications. They can also be accessed through software components or other services. It is much easier to verify browser environments to check for bots in a traditional web application. Browser verification does not work well for APIs which makes them more vulnerable to bot traffic.

Perhaps the biggest difference is the sheer number of APIs organizations use, which in turn creates a huge amount of requests. Organizations can deploy hundreds, or even thousands of APIs. Keeping track of all of these APIs can be a challenge in themselves. Securing them is another beast entirely. For example an organization utilizing a microservice architecture can accumulate vast amounts of APIs. The image below shows David Hahn presenting Netflix’s microservice architecture in one flow diagram. 

Sourced from Medium.com

If not properly maintained and secured these 700 microservices become a logistical nightmare. And it’s no wonder that APIs can pose a security risk. Those 10s of operations engineers have a monumental task when it comes to keeping up with all of the APIs in use.

Tip 3 – Inventory APIs

The large quantities of APIs that organizations deploy can make creating an inventory of APIs a challenge. This is especially true for a company that has already deployed many APIs that are not inventoried in one accessible place. A silo is a term that is used to describe something, whether it is data or APIs, that is collected and not available to other parts of the organization. Creating an inventory can be extremely challenging when multiple API silos exist.

APIs become isolated from one another in different silos in several ways. Disconnected governance is often involved. Different departments may develop their own APIs and not share the information with one another. APIs created using different tech stacks (for example a tech stack for hybrid cloud deployments vs deployments that are completely on the cloud) can create multiple silos. Mergers and acquisitions are another way in which disconnected governance takes effect. And finally some APIs have become outdated and forgotten. These outdated and forgotten APIs are known as “zombie” APIs. These APIs are often falsely assumed to have been “killed” (or decommissioned) until they rise from the dead and are exploited by a hacker.

The simplest solution to this problem is also one that is unrealistic. It would be to encourage a company to prioritize creating an easily accessible inventory before they have developed their first API. Then tell them to send information to employees about the importance of communicating API creation. If this fictional company undergoes a merger, make sure that they only do this with a company who shares their inventorying values. And that all parties involved bring their zombie killing A-game.

For most companies who have realistically already deployed APIs, the task can be more difficult. API discovery involves mining API traffic metadata. Metadata can be mined from API gateways. Oftentimes third party tools are used to search, but the principle is that by locating traffic a company can begin to properly inventory APIs. Even if it takes more time after APIs are already deployed, it is never too late to start making improvements to API inventorying.

Tip 4 – Know the tools at your disposal (and their limitations)

Two commonly used tools for API security are API gateways and Web Application Firewalls (WAFs). API gateways act as an opening between the customer’s requests and the API. The gateway receives requests (known as API calls) from customers who are using the application. It then groups the requests and sends them to the APIs, which in turn sends the services needed to fulfill those requests to the gateway. Finally they are then delivered to the customer. API gateways also handle some security features such as authentication, rate limiting, and protocol translation. They further separate clients from the back end while providing security and traffic monitoring services as well. 

API gateways provide benefits for traditional monolithic architectures, but are especially important for microservice architectures. They can gather requests and send them to the appropriate microservice, gather the microservices responses, and deliver them to the customer. Because microservice architectures utilize so many different microservices the API gateway’s efficiency in handling requests becomes critical.

WAFs enable you to allow, block, or count web requests based on a customizable set of rules. The basic premise is that it blocks harmful traffic from entering into the API while allowing legitimate requests to pass through. Both WAFs and API gateways are worthwhile tools to improve API security. They are able to block some malicious traffic as well as help the API run more smoothly. With that being said, if an attacker is motivated there are limits to the security of these tools.

Most of the security API gateways provide can be circumvented. For example the gateways provide security by providing authentication and authorization services. Relying on authentication however is based on the false assumption that once trusted users will continue to remain trusted. In reality accounts can be hacked, credentials can be stolen, and accounts can be bought and sold on the dark web. These gateways are not always enough to fully protect all critical vulnerabilities

WAFs can identify well known attack vectors, such as SQL injection, but can’t analyze and determine traffic of malicious actors who are exploiting flaws in the API. Once again this brings up the point of business logic flaws. Another limitation of a WAF involves DDoS attacks. These are a very commonly used attack vector against APIs. As DDoS attacks have increased in sophistication they are now perfectly capable of bringing down a WAF. Oftentimes DDoS attacks are used in conjunction with another attack, so that while the DDoS attack brings down the WAF another attack can slip through.

Tip 5 – Know who the API consumer is and where the API is available

The API consumers are the developers or partners who integrate APIs in their apps or web sites for the end user. There are three types of API consumers. These are: private, partner, and public. Private consumers refer to APIs that are only available to internal teams in an organization. Partner APIs are designed so that an organization’s partners can communicate with that organization. And Public APIs are intended for anybody who wants to have access.

These APIs can be available in one of two ways- internally and externally. Internal APIs are only available within an organization and are not available on the open internet. External APIs on the other hand are available on the internet.

It is important to know this so that APIs exposed externally do not have access to more sensitive information than they need. Let’s take a look at a vulnerability from OWASP titled API3:2019 Excessive Data Exposure. OWASP says “Exploitation of Excessive Data Exposure is simple, and is usually performed by sniffing the traffic to analyze the API responses, looking for sensitive data exposure that should not be returned to the user.” 

A leaky API refers to an API that serves more personal data than it is required to. Attackers are able to find APIs that are supposed to be hidden by reverse engineering front ends and scraping for API traffic. When this happens it is often the case that a private API was made available externally.

To illustrate all of these points Peloton’s leaky API from 2021 provides a perfect example. In this case the API was only intended for Peloton consumers (Peloton bikes and Peloton apps). This means that the consumers for the API were private. However, the API was not available internally, but instead externally. While it was hidden from view hackers could still find a way into the API. 

To remediate this OWASP suggests the following:

• Never rely on the client side to filter sensitive data.
• Review the responses from the API to make sure they contain only legitimate data.
• Backend engineers should always ask themselves “who is the consumer of the data?” before exposing a new API endpoint.
• Avoid using generic methods such as to_json() and to_string(). Instead, cherry-pick specific properties you really want to return
• Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls returning such information to see if these responses pose a security issue.
• Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism define and enforce data returned by all API methods, including errors.

Tip 6 – Ensure you know which of your APIs expose sensitive data

This leads us to our final tip, which is really an extension of the last one. Accidental exposure of sensitive data such as PII and PHI creates a lot of risk for not only a business, but their clients as well. A recent Salt Security survey asked how confident the respondents were that their API inventory provided enough detail about their APIs, including exposure of sensitive data or PII. Only 14% were very confident, and 20% were either not very confident or not confident at all. Care should be given to having a record of every API that exists within an organization and what information those APIs contain.

Conclusion

API security should not be ignored. The sooner organizations get ahead of securing APIs the better off they will be. Not only will it limit risks of breaches and data leaks, but it will also be easier to do the earlier security is put in place. Before API silos get out of hand organizations should make API inventories a standard practice. Knowledge of what information their APIs store will better direct where these APIs should be exposed. As organizations shift security left, security increasingly starts in development and should continue throughout an APIs runtime all the way until its “death”. Our article on shared responsibility of API security explains how to do this so that API deployment is as quick and secure as possible.