The OWASP API Security Top 10 demystified

Useful as they are, OWASP Top 10 lists are not renowned for being clear and readable, and definitely not for being fun. While we do have a serious post discussing the methodology, categories, and missed opportunities of the OWASP API Security Top 10 for 2023, this time we thought we’d take a more light-hearted look at the big ten for APIs. And this is not (just) goofing around—by cutting through the precise formal language, we can hopefully get a better feel for each API risk category.

API risk #1: Ask and you shall receive

API1:2023 Broken Object-Level Authorization (aka BOLA aka IDOR)

The whole point of APIs is to provide automated access to application data and functionality. Setting up an API endpoint to serve up the details of a customer account is easy—the big challenge is to make sure that data is only accessible to authorized users and systems. If something (the “object”) in your app can be freely accessed by anyone just because they know how to request the right URL and object ID (like a customer number), you get data breaches like the Optus hack.

API risk #2: You don’t need to see his identification

API2:2023 Broken Authentication

With APIs, as in life, proving your identity is the first thing you should be asked to do before doing anything important. If this authentication mechanism is weak or easy to bypass, malicious actors can get in without any questions asked, using methods ranging from brute-force credential stuffing to tampering with a JWT token to bypass signatures. And once they are in, the remaining top 9 risks are up for grabs.

API risk #3: Promise me you won’t look inside

API3:2023 Broken Object Property-Level Authorization

With most business applications, it’s pretty obvious that different users need different levels of data access. If you have a customer account in the system, some of your staff may only need basic contact information, others will also be trusted with financial information, while an admin user may have access to everything plus credential management. Enforcing this for API access is especially difficult, leading to situations where an attacker who gets access to a customer account object also gets access to all the data for that account.

API risk #4: I don’t expect you to talk, Mr. API. I expect you to die

API4:2023 Unrestricted Resource Consumption

Data breaches tend to make more headlines, but attackers don’t always need your API to talk—knocking it offline along with the whole app is often enough. Denial of service (DoS) attacks are among the crudest yet most common ways to target an API, made all the easier by APIs being specifically designed for silent and automated access. Accepting and processing every incoming request without enforcing any limits leaves an API vulnerable to resource exhaustion and its owner exposed to excessive operating costs.

API risk #5: Are they allowed to do that?

API5:2023 Broken Function-Level Authorization

API endpoints expose not only data but also operations on that data. While risk #3 was related to attackers getting all-or-nothing access to data objects, the same applies to permitted operations. REST APIs, in particular, commonly expose methods that include. GET, PUT, and DELETE. If anybody who can read data through a regular GET request is also able to delete it by just manually changing GET to DELETE in the request header, you are clearly asking for trouble. The same goes for unsecured access to things like admin operations.

API risk #6: Hey, that’s cheating!

API6:2023 Unrestricted Access to Sensitive Business Flows

Abusing automated access to certain operations might have serious business consequences, even when it’s not technically a security risk. Common examples include automatic auction bidding, buying out and then reselling high-demand items like tickets, or flooding a reservation system with requests to deny it to legitimate users. So while it might not knock the service offline like a DoS, it can certainly cause business disruption and material losses. Plus it’s cheating.

API risk #7: Give them a fake address; they never check anyway

API7:2023 Server-Side Request Forgery (SSRF)

Fetching resources from an external site is a common practice in web development. When working through APIs, it is equally common to get the specific resource address (URL) from an incoming request. Without careful validation to catch any unexpected data in that URL, an attacker could send you the URL of a malicious external resource, including malicious code. Even worse, they could also request a sensitive internal resource—and because the request is coming from your API server, they could indirectly access internal systems via your API.

API risk #8: Amazing, that’s the same code I have on my luggage!

API8:2023 Security Misconfiguration

Setting up a production API to work correctly is not easy, and making it secure is even harder. Even a single security misconfiguration anywhere in this multi-layered technology puzzle could leave attackers with a way to access API data or operations. Examples include unpatched products or software components anywhere in the tech stack, excessive permissions at any level of that stack (especially for cloud storage permissions), and weak security (such as gaps in encryption) at any stage of API request processing.

API risk #9: New building, same unlocked fence gate

API9:2023 Improper Inventory Management

When an API changes, it’s common practice to set up the new version alongside the old one to make sure existing systems that rely on that API still work until the transition is complete. Without careful inventory management, those old APIs can easily be overlooked and forgotten, remaining accessible to attackers. And because they are old and abandoned, they are less likely to include the latest security updates and might not be monitored and protected to the same level as production APIs, giving malicious actors plenty of time and opportunity to find a way in. This is why API discovery is such a big deal.

API risk #10: It’s always a friend of a friend that causes trouble

API10:2023 Unsafe Consumption of APIs

For the most part, APIs don’t interact with humans but with other APIs—and those, by design and unlike humans, should behave according to spec. This may create a sense of implicit trust, leading developers to unquestioningly accept and pass on data from a familiar third-party API, especially one operated by a well-known company. If attackers compromise that API or manage to slip malicious data into one of its data sources, blindly trusting results received from that API could leave your own application vulnerable or compromised.

Final thoughts: Are you talking to me?

When put into everyday language, many of the top 10 API-related security risks might seem simple, even mundane—mostly different ways of letting attackers access things they clearly have no business accessing. The challenge with APIs is that they act as shortcuts to the internals of your application. Unless those shortcuts are carefully planned from the earliest stages of application design and development, they can bypass access controls that might be present in the application.

It’s always tempting to treat any OWASP Top 10 as a security checklist, but the goal of the API Security Top 10 is clearly stated in its introduction: “to educate those involved in API development and maintenance, for example, developers, designers, architects, managers, or organizations.” You’ll note that security folks aren’t listed—because API security really starts way before they come in with testing and protection.

The main takeaway from the OWASP API Security Top 10 is that, in a perfect world, secure APIs should always start with secure application design. In the real world, though, APIs are rarely perfectly designed, implemented, or tracked, so tools for API discovery and API security testing are a vital part of any application security toolbox.

Learn more about Invicti API Security and check out our free (and ungated) white paper: API Vulnerability Testing in the Real World.