Wallarm — OWASP — 2023 OWASP Top-10 Series: API10:2023 Unsafe Consumption of APIs
In OWASP

2023 OWASP Top-10 Series: API10:2023 Unsafe Consumption of APIs

3 Mins Read

Welcome to the 11th post in our weekly series on the new 2023 OWASP API Security Top-10 list, with a particular focus on security practitioners. This post will focus on API10:2023 Unsafe Consumption of APIs.

In this series we are taking an in-depth look at each category – the details, the impact and what you can do about it. To see previous posts you might have missed, click here.

TL;DR

APIs are meant to interact with other APIs, but if your API is blindly trusting other APIs, then you’re engaging in unsafe consumption and might fall victim to attacks from a compromised API.

The Details

Input validation and sanitization are hardly new concepts. Encrypting communications isn’t a novel idea either. So why are these a particular concern for APIs? The answer has to do with their usage. APIs are generally built to interact programmatically, and most often with other APIs. After all, when we expect a human being to use an application, we generally build an interface for them. While we understand that human beings are inherently unpredictable and occasionally malicious, there’s a tendency to assume that other applications and their APIs are the opposite: predictable and benign. That’s not always the case, however. 

In fact, API10 is all about implementing basic best practices when interacting with other APIs. This OWASP entry is meant to capture all the basics you might choose to skip if you think “it’s just another API; what could go wrong?” 

Encrypting communications should seem like an obvious best practice. If you’re not considering it a basic requirement, then you’re putting your APIs at risk. 

Resource management is another basic best practice. There’s definitely overlap here with API4:2023 Unrestricted Resource Consumption. If you’re not implementing restrictions on how other APIs can use your resources, then you’re putting your APIs at risk. 

Input validation is a bigger topic when compared to some of the other issues addressed by API10. The attacks that leverage missing input validation are generally injection attacks, which has been subsumed into API10 in the 2023 update. We’ll address injection threats more directly in our next post in the series. 

Suffice it to say, lack of input validation has been causing problems in code for decades, and APIs are no exception. If a third-party API has been compromised by an attacker, then it might be used to attack other APIs to which it has access. This OWASP API Security Top 10 vulnerability is intended to capture this situation. 

In the end, these are just examples of how an API might be an unsafe consumer of other APIs. It’s important to understand the principle that just because you’re interacting with an API, doesn’t mean you’re not at risk.

What’s the Impact?

This OWASP entry isn’t just a single vulnerability, but a collection of conditions, and so the impact is also a collection of possible outcomes. A lack of encryption leads to loss of confidentiality in the data transmitted between APIs. A lack of resource management results in a denial of service, or the loss of availability.

Of the examples we’ve discussed, the injection flaws are arguably the most serious because they provide the ability to directly compromise an application or access the data behind it. In the end, specific impact is determined by the threat model for the specific application, but the loss of confidentiality, integrity, and availability are all possible. 

What Can You Do About It?

Potential actions to mitigate API10 fall into two categories: remediating your own APIs and managing the risk of third-party APIs. 

For APIs that you control, implementing basic best practices like encrypted communications and granular access control are the right approach. Make a checklist of controls that should be in place and evaluate APIs against them. Of course, detecting and blocking attacks, regardless of their source, is a key control to implement. 

For APIs that you don’t control, whether third-party partners with which you integrate, APIs in commercial off-the-shelf-software, or open-source products, a similar approach can work, except you’re validating instead of implementing. In other words, create that same checklist, but ask the partner or vendor to comply with it. Before engaging in these conversations, establish your response plan when a vendor/partner doesn’t meet the requirements. This checklist should be part of your overall vendor security process, and the earlier you gather answers, the better.

How Wallarm Can Help

Wallarm detects and blocks the attacks that are part of this OWASP entry. The Wallarm nodes monitor API traffic to identify and block remote code execution, SQL injection, server-side request forgery, and more. Wallarm also tests your APIs and endpoints for vulnerabilities that might make them susceptible to these types of attacks. By employing active blocking and vulnerability assessment, Wallarm can help protect your business critical applications while simultaneously helping you reduce risk.

Learn More

Come back next week as we dig into the details of another category of the new 2023 OWASP Top-10 API Security Risks list – or click here to see previous posts you might have missed.

In the meantime, here are some other resources which might help on your journey to end-to-end API security:

Protect Your APIs from OWASP API Security Top-10 Threats

Wallarm End-to-End API Security solution provides comprehensive protection against the OWASP API Security Top-10 threats. And in 2023, we’ve made it even easier for you!

The Wallarm 2023 OWASP API Security Top-10 Dashboard provides you with complete visibility into the security state of your APIs, easy identification of your most critical security risks, and ability to immediately apply protective measures.

If you are interested in learning more about how we can help you protect your APIs, please schedule a demo with one of our security experts today!

Related Posts