The Problem with APIs

As we all know by now, APIs are everywhere and in every part of our lives. Without them, the modern internet as we know it would not function. However, with all these benefits come a variety of risks and downsides. In recent years, attackers have been increasingly targeting APIs. 

But this brings the question: How do you secure an API, and whose responsibility is it?

Let’s start by going over what an API is…

API stands for Application Program Interface. APIs are essentially how different applications communicate with each other. They are the connective tissue between programs on the web, talking to one another to power all of the digital interactions we take for granted from mapping to food delivery, booking services, online shopping, and more.

But where does an API fit into the technology architecture?

APIs are written as code and are a key part of applications. They live on a network, so they have requests going in and out via network protocols. APIs can be breached via authentication and authorization, or identity flaws. And as of the mid 2010s, most APIs are built on Cloud and deployed in Cloud environments.

So how do you start securing an API?

With this understanding, you might think that API security falls into one of those five categories:

But what security techniques are most relevant?

Let’s break it down. 

A strong API security posture should include the following…

1. Static code analysis (SCA): Teams need to analyze the design of the API and look for flaws in the original code itself.
2. Application Security Testing: They also have to check the exposed endpoints of the API and test for flaws and vulnerabilities.
3. Network security: Security teams might network traffic analysis techniques to detect threats and anomalies.
4. Identity and Access Management: The data shows that authentication and authorization are the two most common breach vectors for APIs. Teams must enforce strong authentication and authorization on API requests.
5. Cloud Security Posture Management / Cloud Native Application Protection Platform: Security teams should use the attack paths to key data assets that involve APIs or are exposing APIs at the outermost edge of the attack path.

This all sounds like a lot… because it is. But can any organization really do all of these things? And how do we prioritize? 

Building a threat-informed defense & security strategy for your APIs

Let’s look at the data…

As per the State of API Security report, API attacks have risen by 80%  from 2017 to 2023. 

Of these attacks, over 78% involve vulnerabilities with authentication and authorization. The results of these attacks are that over 1.6 billion records have been exposed and more than 158,000 issues have been identified. So clearly identity is a key part of the API threat model.

So what can we do?

The first step is discovery. Many organizations don’t even know all the APIs in their landscape, and many breaches happen as a result of unknown and unmonitored APIs. 

Since most breaches happen because of authentication and authorization issues, identity is key, and this is embedded in the design of the API. Customers could turn to externalizing these identity-related functions, but that may be challenging for both existing APIs or if the company doesn’t have a good authorization graph construct. Therefore, design analysis, specifically SCA, is the most effective technique to find these design flaws.

While network telemetry and network traffic analysis can be helpful tools, they don’t provide the real-time blocking capabilities needed for a holistic API security posture. Similarly, Web Application Firewalls (WAFs) and Gateways don’t look at the right levels of data to make deterministic decisions about “good VS bad” API calls. 

All these things mean that actual runtime protection needs to be evaluated differently. Proper API security needs to be embedded in the code, but for many organizations, this is challenging because it means that security teams need to work with developers to get this implemented in the first place. This brings us to the next age-old question…

Who owns API security?

While developers build APIs, security isn’t their job, nor is it even a primary focus for them. And while security teams are responsible for API security, they often have little to no control over the actual design of the API, which means they cannot get the level of logging that they need for proper API security.

A proper API security solution needs to bridge that gap between security & developers. 

Developers and security teams need to work together, even though their needs are different. Security teams need central visibility, risk analysis of the APIs, and adequate logging. Developers, on the other hand, need guidance on best secure practices for building and shipping APIs. Without these things, neither one will be able to do their job properly, and are destined to fail at building secure APIs.

Takeaways

APIs are the most crucial component of the modern-day web as we know it, however API security is a complex issue to tackle, and becoming increasingly difficult as attacks rise in both volume and complexity.

Properly securing APIs begins in the design and the building process with the developers, but they alone cannot be responsible for the security of their APIs. Security teams hold the job of ensuring APIs remain secure, but without enough analysis from developers on the APIs design, they cannot do their job properly. So security teams and developers must perform a delicate dance of ensuring that they are sharing enough information with one another to build secure APIs starting with the code, and protect them all the way through to the Cloud.

The actual process of creating a strong API security posture contains many moving parts, but the key things to emphasize are authentication and authorization, as they are the two biggest issues faced by APIs in the modern cyberspace.

To learn more about API security and see how FireTail can help you with your API security posture, set up a free 30-minute demo or try it out yourself for free today.