Does the new OWASP Top 10 accurately reflect the threats now facing APIs? [Q&A]

Application Programming Interfaces (APIs), which act as the glue connecting systems and applications together, are now the number one attack target for cyber criminals. Attack methods have changed over recent years, however, prompting the OWASP API Security Project to revise its API Security Top 10 of attack types for 2023.

But do the tactics, techniques and procedures (TTPs) it covers still serve as a blueprint for defense? We spoke to Jason Kent, hacker in residence at Cequence Security, to find out if the top 10 is liable to see defenders take too narrow an approach.

BN: Why is API security such a hot topic right now?

JK: APIs are now the building blocks of the digital age as they can be rapidly spun up and provide ready access to applications and services. But that same convenience is also their downfall because attackers can use reconnaissance to look for and exploit insecure or unprotected APIs, while their ubiquity means keeping track of and managing them is difficult.

Unfortunately, many organisations aren't aware of the nuances of APIs that can make them susceptible to attack. They've continued to rely upon web application security solutions such as Web Application Firewalls (WAFs) to protect them or API Gateways which are designed to channel APIs, so there's now a massive potential attack surface for threat actors to exploit. In fact, The API Protection Report found there was a 900 percent increase in the number of shadow APIs (i.e. APIs that organisations don't have visibility of and aren't protecting) during the second half of 2022.

BN: How did the OWASP Top 10 come about and how is it put together?

JK: The OWASP Foundation is a non-profit that works to improve the security of software and they do a fantastic job of underscoring the potential risks in APIs and how they can be mitigated.

The OWASP API Security Project devised the first iteration of the Top 10 in 2019 and has just released the latest version which was put together from input from those within the industry, ourselves included. All those involved have opinions of what they think the list should look like and it’s the team's unenviable job to make something meaningful from that which reflects the world of API security as well as meeting demands from a compliance perspective.

BN: What's changed in the new OWASP Top 10?

JK: Those at the top of the list, namely API: Broken Object Level Authorization (BOLA) and API2: Broken Authentication, remain largely unchanged. As the list progresses, we see either redefinitions that aim to be more inclusive of issues or the introduction of new concepts, reflecting how TTPs have advanced.

The redefinitions are helpful. API6, for instance, was Mass Assignment and is now Sensitive Business Flows. The greater clarity in the new name and definition allow for API6 to now reflect an issue we’ve been highlighting for some time, which is that if the API isn't operating securely, it's susceptible to attack automation i.e. bot attacks.

BN: Do the changes accurately reflect threats and their voracity?

JK: One of the issues which, at first glance, appears to have been replaced on the list is API3 which was Excessive Data Exposure. Does this mean we’ve solved that? No, sensitive data exposure is a huge problem. What happens in API3:2023 is that the issue is taken to the next step which is breaking through property level authorization. It zones in on that next stage and that’s because sensitive data exposure is a problem that's much more generic in that it can permeates every item on the list. I don't think it's necessarily helpful, however, because by doing that you’ve effectively declassed a very serious issue.

BN: The OWASP list has always been the go-to API document for defenders. Does the format still have relevance today?

JK: A Top 10 is easily digestible and understandable and in that sense it achieves its purpose in terms of heightening awareness. But the reality is that these attack types are no longer standalone assaults -- they're used in concert with one another -- and if you ignore that, it becomes very difficult to successfully defend your API estate.

If we look at a typical breach scenario today, we can see that the future holds very different problems to the past. Many breaches start out with an API that the victim organization was unaware they had (a shadow API) which is covered under API9 in the 2023 list. This API is found to return data about a user that isn’t the attacker which is classed as API1 (BOLA). Then the attacker decides to exploit this as quickly and as fast as possible by creating an automated attack using a bot reflected in API6. Such an attack therefore touches on at least three of the ten attack types and by doing so ensures the threat actor gains maximum access to the sensitive data that the API was privy to.

I'd argue that the Top 10 is a great place to start but for defenders it’s a bit like giving a mechanic a car brochure instead of the manual. If you really want to get to grips with API security, you need to develop an understanding of how attackers are using these TTPs to pivot their attacks.

BN: How would you like to see the approach to API security move on?

JK: The landscape of API security is always changing and organizations need to change with it. Whether it is knowing where your APIs are, testing them for flaws or mitigating bots attacking your unknown flows, API security needs to be proactive and at the top of the agenda for the business.

The Top 10 does a great job of illustrating API abuses but security teams need to go that step further and think like an attacker. Taking both an external as well as an internal view of your API estate is a must, enabling the business to detect all publicly exposed API servers and endpoints.

In addition to this discovery element, we also need to focus on detection which needs to move beyond signature-based detection methods to behavioural analysis. Perfectly coded APIs can still be compromised and often the only giveaway is a change in traffic and/or the type of requests sent to the API, which is why there needs to be continuous monitoring.

And, in the event of a compromise, you’re looking at how you mitigate that threat whether that be through blocking or diffusion. In the case of a persistent attack, for example, the defender may well need to frustrate and fatigue the attacker as they pivot through TTPs.

All of these stages of defense need to be considered and processes put in place to enact them but we also need to consider the lifecycle of the API. So defense needs to be a factor from development through to production and replacement/retirement.

We've come a long way in the past four years but given the vast sea of APIs that are now deployed and continually being added to, we need to up our game.

Photo Credit: Panchenko Vladimir/Shutterstock