How to Protect APIs

The way we need to protect APIs has changed. APIs have become the critical enablers for today’s digital economy. APIs have not only transformed how we build modern day applications and services, but have also transformed how we live. APIs enable you to pay for your morning coffee using a digital wallet. APIs allow you to make instant payments and purchases straight from your mobile phone. APIs make it possible for you to check your banking account balances, order food delivery, or schedule transportation from any location and at any time. Name any online application — they all need APIs to function.

APIs aren’t new; however, although APIs have been around for a long time, their growth has skyrocketed over the past few years. Cloud computing, advanced devops processes, and other modern technologies have made it easier and faster for developers to build and deploy APIs, and the COVID pandemic has hastened their adoption for digital services.

In the past, it used to take days to write an API. Today — due to serverless functions, microservices, containerization, Kubernetes, and other advancements — APIs can be written and exposed within minutes. Given the exponential growth of APIs and the huge volumes of API calls, protecting APIs has become challenging.

Attackers have recognized the wealth of valuable data that APIs transport and the opportunity they present. As attackers have jumped on the API bandwagon, API threats have also changed, contributing further to the risks and demanding a new approach to protect APIs.

Protecting today’s APIs requires that organizations:

• Maintain an accurate inventory
• Understand the new attack paradigm
• Become educated about top API vulnerabilities
• Implement runtime protection

Maintain an accurate inventory

Organizations must have a complete inventory of the active APIs within their infrastructure before they can even start to ensure API protection. “Shadow” or unknown APIs, and “zombie” or outdated APIs, represent an ongoing security risk for organizations. In fact, organizations have named outdated APIs as their biggest API security concern for the last four editions of the Salt Security Salt Labs State of API Security report.

However, gaining a complete inventory is not as simple as it sounds. API discovery contains many layers and can be highly complex. For example, while organizations may be aware of an API, there could be one change — a single vulnerability — that a developer accidentally included, such as accidentally exposing a token in a response, that can make that API an unknown risk. That is why API discovery should do more than just let you know that an API exists. API discovery should expose this type of vulnerability, tell you how an API is being used, and inform you about the data it ingests and exposes.

In addition, establishing your API inventory is not a one and done endeavor. Your inventory needs to be continuously and automatically updated to manage your risk and exposure. Ongoing API discovery is essential to protect your APIs, particularly given the fast pace of API updates. According to Salt Labs research, 31% of organizations update their APIs weekly and 11% update APIs daily!

Understand the new attack paradigm

As the number of APIs has increased, the threats themselves have changed. This new attack paradigm has arisen because APIs have been built upon business logic and underlying application logic. The most significant API security risks stem from business logic flaws.

Transaction-based attacks — such as a typical SQL injection — comprised the majority of past security attacks. Traditional front line, proxy-based security solutions, like a WAF, work well at stopping these types of attacks; WAFs look for known patterns and act as a firewall, blocking the known bad. However, server- or VM-based API security approaches simply don’t have a broad enough data set over time to identify today’s sophisticated API attacks.

In application logic attacks, hackers poke and prod — over and over again — to uncover holes in coded business 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 pin-point, low-traffic, application denial-of-service (DoS) attacks.  

Because of this, attacks rarely stem from a single API call. Attackers make multiple API calls as part of their reconnaissance efforts. While traditional security solutions can defend against known vulnerabilities, they cannot discover these logic-based API vulnerabilities. They lack the needed business function and logic.

To protect APIs, organizations must be able to spot logic-based vulnerabilities in APIs. This requires business function and business logic context. Security teams must see the API’s endpoints in action and understand the functional purpose of each of the endpoints. They also need to understand the behavioral characteristics of each parameter and element in use by those endpoints. A single API endpoint alone can have thousands of possible permutations of business and underlying application logic that need to be vetted and exercised in order to understand if the endpoint is capable of performing any negative behaviors.  

Become educated about top API security vulnerabilities

To help businesses understand and mitigate unique API vulnerabilities and the growing threats against them, OWASP published the OWASP API Security Top 10. Despite the immense value to be uncovered in this list, findings show only 55% of organizations currently use it as part of their security program, making it an underutilized resource.

If you want a good starting point to learn about the common weaknesses and security flaws that can exist within APIs, there is no better place to start than with this list. The OWASP API Security Top 10 list includes detailed descriptions and example attack scenarios for threats.

Of the 10, the most common are: BOLA (broken object level authorization); broken user authentication; excessive data exposure; and security misconfiguration. It is also worth noting that the majority of the OWASP API Security Top 10 vulnerabilities derive from business logic flaws. Below is a brief overview of the four top API security vulnerabilities:

• BOLA

Broken object level authorization is the most common API threat, accounting for about 40% of all API attacks. The scary thing about a BOLA vulnerability is that many times the attacker does not have to do much to take advantage. Manipulating a singleID parameter within a header or body of an API request is sometimes all it takes.

• Broken User Authentication

Broken user authentication vulnerabilities allow attackers to use credential stuffing techniques with known or stolen authentication tokens or credentials, and brute-force attacks to gain unauthorized access to applications. Attackers can take over user accounts, gain unauthorized access to another user’s data, and make unauthorized transactions. In some cases APIs containing sensitive data are published with no authentication or authorization gates in place at all, giving an attacker free, unchallenged access to sensitive data.

• Excessive Data Exposure

When generic APIs provide more data than is needed, an attacker can exploit an application by using redundant data to extract sensitive data. APIs often send more information than is needed in an API response and leave it up to the client application to filter the data and render a view for the user.

• Security Misconfiguration

A wide range of security misconfigurations exist that often negatively impact API security as a whole and can inadvertently introduce vulnerabilities. Security misconfigurations can include insecure default configurations, incomplete configurations, misconfigured HTTP headers or HTTP headers with detailed system information, verbose error messages, open cloud storage, and more.