Are All Your APIs Insecure?

Bruno Pedro
5 min readMar 10, 2022

This is API Changelog’s Big Question for the month of March 2022. Big Question is a monthly rubric that focuses on one single topic and explores the existing information. Subscribe now, so you never miss an issue of the API Changelog.

Digital Collage by Bruno Pedro
Digital Collage by Bruno Pedro

Saying that all existing APIs are insecure feels like a strong statement. At least that’s what Mehdi Medjaoui, the founder of the apidays API Conference, thinks. He recently started a Twitter space dedicated to APIs, and on February 9, 2022, during the first episode of APIs and stuff, Mehdi mentioned something intriguing. It appears to me that some apidays speakers have been claiming that existing API Gateway solutions can’t protect any of your APIs. I was participating in that discussion and immediately felt curious to know more about it.

To be more precise, the claim is that existing API Gateway solutions can’t always provide enough security against common attacks such as man-in-the-middle (MITM) and account takeover (ATO). These types of attacks are directly related to cryptographic failures, one of OWASP’s top 10 security risks for 2021. Additionally, broken user authentication and injection are two OWASP API Security related risks. According to Jason Kent, a hacker-in-residence at Cequence Security, ATO attacks on APIs increased by 62 percent between June and December 2021. Attacks are more prominent on companies with a strong social presence. In this case, the goal of the attackers is to hijack media accounts that they can be use to amplify information to millions of followers. Isolated actors do not perform most ATO attacks. Instead, attackers use bot networks that can execute a high volume of attacks in a short period. It feels like there is something worth investigating.

I had to find better ways to understand what was going on, so I spoke with Dinis Cruz, a former OWASP Board Member and CISO of Glasswall Solutions. Dinis’ opinion is that most companies don’t know how consumers use their APIs and can’t identify what constitutes an attack and what doesn’t. That happens because companies haven’t put the appropriate API observability solutions in place. Additionally, according to Dinis, another area that needs more attention is API usage management. In other words, companies should be able to detect suspicious API usage patterns and take adequate measures to prevent the escalation of an attack. In short, while observability alone wouldn’t help you, being able to block certain users would let you provide a quick response to MITM and ATO attacks. On top of that, Dinis recommends that you work well on your Software Development Lifecycle (SDLC) by injecting automation as much as possible and adding security review and testing as gatekeepers. Even after knowing all this, I couldn’t feel better, I must admit.

If MITM and ATO attacks make you feel insecure, then you should know that some people think they’re just the tip of the iceberg. I asked Elimane Prud’hom, a Sales Director at Salt Security, what are the biggest concerns you should pay attention to. Elimane painted a dark picture by mentioning that there’s a good chance that more than 90% of all companies that have an API suffered an attack in the last 12 months. So, it looks like virtually everyone has been a target of some type of security attack — including you! The biggest security risk is, not surprisingly, not knowing what are the APIs that you have and what the attack surface is. Companies typically underestimate the number of APIs in operation by 40% to 80%, and it’s the unknown APIs that can become a security risk. According to Elimane, attacks can be prevented but not by API Gateways alone. That is because API Gateways don’t have all the information to detect abusive usage patterns and generate enough insight to mitigate an attack. Even with all the required information, they wouldn’t be able to provide enough processing power to act in real-time.

One of those API Gateways is Kong. The software appeared first in 2015 as a byproduct of Mashape, a popular API marketplace at that time. Mashape saw an opportunity in the API Gateway market and grew Kong, making it its sole focus, with a total of more than $160M raised until 2021. Let’s see how Kong, a popular API Gateway, can deal with security threats such as MITM and ATO. To understand that, look at their release 2.8 announced on March 2, 2022. One of the highlights of the release is the increased security that the new version can provide. One of the things I noticed is that Kong now offers something called secrets management that, supposedly, will increase security by centralizing the way privileged information is stored and accessed. Secrets include, among other things, privileged account credentials, passwords, X.509 certificates, and also API keys. Privileged information can be stored in third-party secret management solutions such as the popular Vault from HashiCorp, and the AWS Secrets Manager. This feature sounds great, but it doesn’t provide the API Discovery that Elimane was referring to, nor the right observability and threat mitigation that Dinis was mentioning. So, it looks like the API Gateway alone can’t provide enough security.

Kong actually acknowledges that it doesn’t have a full API security solution and offers a solution through Neosec, one of its partners. With this type of solution, you would get a full inventory of all your APIs, a behavioral analytics system capable of detecting suspicious usage patterns, and also a mitigation system that can be used to block malicious activity. Salt Security also has an integration with Kong, even though it’s not an official one. The Salt Security Kong integration lets you capture all your API traffic for subsequent analysis and mitigation. With a combination of Kong and one of these security companies, you would have enough protection against the latest API security threats. You could probably have a similar result with a combination of different API Gateway and Security solutions. What’s important here is to understand what is at stake when it comes to API Security.

Are all your APIs insecure? The answer is that it depends. It depends on what API Gateway solution you’re using, and how you’re logging your API usage. It also depends on your ability to analyze API usage and detect suspicious patterns, and on having the correct mitigation tools in place to act quickly. If you have the answers to these questions, you’ll be able to understand if your APIs are insecure. More importantly, I think, is that you’ll also understand what you need to do to increase API Security.