When developers and IT engineers think about IT security, they tend to break it down into several niches. There’s AppSec, which focuses on securing applications. There’s infosec, which deals with protecting data. There are practices like CSPM and CIEM, which help to secure cloud infrastructure.
But here’s another critical security domain that many teams overlook: API security. Although there is certainly some discussion of API security today, it doesn’t tend to receive as much attention as other categories of risk.
Here’s why that’s a mistake, and how companies can fix it by making API security a first-class component of their overall security strategies.
If you look at some of the most significant cybersecurity breaches in the past, you’ll notice that many of them were facilitated by API security issues. Examples include:
- The T-Mobile breach, in which attackers exploited an API to scrape customer data.
- LinkedIn’s exposure of 700 million customers’ data, also due to an insecure API.
- A vulnerability in a Coinbase API that allowed attackers to essentially sell an inexpensive coin for BTC due to insufficient API data validation.
The whole point here is that even some of the largest organizations with a significant focus on software security can fall prey, since API-related security breaches are becoming widespread today.
In a way, that’s not surprising. API adoption has surged in recent years, with developers now using between 10 and 15 APIs in each application they build, on average. Given the proliferation of APIs, it’s pretty understandable why attackers are increasingly focusing on APIs as a vector for breaching applications and data.
API security is made more complex by the fact that there are many ways to exploit APIs. The OWASP API Security Top 10 list summarizes the main risks that organizations face related to APIs. Among the most significant are:
- Broken Object Level Authorization (BOLA): BOLA leads to improper validation of requests to APIs, allowing users to do things like download data that they should not be able to access.
- Broken User Authentication: Even if proper object level authorization is in place, attackers can potentially still gain unauthorized access to resources via APIs by defeating the authentication mechanisms (like tokens) that are supposed to restrict access.
- Excessive Data Exposure: When you expose more data than is necessary via an API, you invite attack. Ideally, APIs should only expose the data they need to expose in order to serve their intended purpose. Your API shouldn’t be an open door to all of the data inside your environment.
These, at least, are the top three API security risks according to OWASP. Check out the complete list for the full scope and depth of OWASP’s recommendations on API security.
The OWASP list is a great foundation for securing APIs. Arguably, however, API security strategies should include additional measures, including requiring access control and avoiding API sprawl.
Require Access Control
One major type of risk that the OWASP list doesn’t address (at least not directly) is total failure to require any kind of authorization or authentication for APIs. If you create a public API – meaning an API that can be accessed by anyone that knows where it is hosted – and don’t require authentication, you get into situations where attackers can scrape vast amounts of data in ways you didn’t intend.
Access controls should be required by default.
Avoid API Sprawl
Another major API security risk is using so many APIs that you simply can’t keep track of where and how they’re integrated into your applications. When you do this, you end up with API sprawl.
API sprawl is bad because it makes it hard to determine the scope of a known API security issue. It also makes it difficult to ensure that all APIs are being used securely.
To avoid API sprawl, establish governance policies that dictate when and under which terms developers may use both internal and external APIs within your organization.
We could go on in discussing major API security risks. This is a somewhat subjective topic, and although security recommendations like those from OWASP provide a great starting point for API security, it’s critical to think as holistically as possible about where API security risks lie within your organization and how to manage them. Sometimes, the most serious security risks arise from very simple mistakes – like failing to keep track of which APIs you are using, or choosing not to require authentication of any type for API requests.
About the Author:
Chris Tozzi has worked as a Linux systems administrator and freelance writer with more than ten years of experience covering the tech industry, especially open source, DevOps, cloud native and security. He also teaches courses on the history and culture of technology at a major university in upstate New York.
To learn more about the many risks (including APIs) in modern application development, download this e-book today.