Common API vulnerabilities

AuthN and AuthZ are just some of the topics that deserve strict care when designing and developing an API. Although they are two separate concepts, they are usually spoken of and discussed together because it does not make much sense to have one without the other. They are not only relevant when dealing with external users. When your application needs to interact with internal systems or partner applications, the same or other controls must be in place. Applications talk to applications, and impersonating an application or an external user is the first vulnerability I would like to talk about.

OWASP, the same organization mentioned earlier, also owns the Top 10 API 2023 security project. Its API Security Top 10 initiative positions API1:2023 – Broken Object Level AuthZ and API1:2023 – Broken AuthN as the two most dangerous threats. The first topic is about not correctly handling access to objects throughout the API execution. This can lead to inadvertent exposure of data, including sensible data, to unauthorized people. So, controls to verify and protect access at the level of objects need to be in place. The second topic is related to what we discussed in the last paragraph of the previous section. Incorrectly handling AuthN data or implementing weak AuthN mechanisms or with known security flaws becomes a very big headache on your API management.

Moving on, we have Broken Object Property Level AuthZ as the third-most problematic threat. APIs vulnerable to this either do not implement or only partially implement the security controls necessary to protect object-level access, which results in data being exposed more than necessary, especially to unauthorized people. It is like Broken Object Level AuthZ, but this vulnerability has to do with APIs displaying more data than necessary to carry out their activities. Next on the list is unrestricted resource consumption. Do you remember, back when we were talking about XML and XMLP, how we mentioned that the way the XML documents are created may lead to security exploitations? This is what it is about. By not correctly parsing the input, an API might suffer DoS, since more processing power or disk access will happen, leading to increases in costs. Imagine the API is running on a public cloud provider and the result of more processing being demanded is the launching of new instances (virtual machines) or storing random data on high-performance disk areas. This would augment the monthly bill exponentially or activate some throttling mechanism – managed by the cloud provider or by your company – that would put the API down or into a dormant state. In any case, the application stops running.

AuthZ issues come up one more time with the next threat. As your API grows in complexity and reach, especially if it touches other systems, you may hit Broken Function Level AuthZ, which means you need to pay close attention to roles and personas created to separate permissions inside the API. When they are not clearly defined and enforced, bad handling of the API hierarchy may lead to vulnerabilities in which a user belonging to a role can purposefully or accidentally (valid users may face this issue even when they do not mean to do so) assume permissions of a higher role. An API does not constitute the whole application. It is part of something bigger and sometimes, various business flows are running to sustain the system. When you have unrestricted access to business flows, a subsequent vulnerability that may arise is the API exposing how such flows are internally structured. Hence, an attacker exploiting this vulnerability could infer the business logic behind the API. This will be covered later.

Server-side request forgery is a very common threat to web applications and APIs, including in cloud environments. A vulnerable API would accept any URI, including running internal commands that could reveal the supporting system behind the API: OS, kernel or library versions, and additional components, among others. It is important to protect the API itself by securely designing and implementing it. There is a saying in Brazilian Portuguese that translates to something like this: “one swallow doesn’t make a summer”. I mean to say that only protecting the API itself is not enough. When a system is vulnerable to security misconfiguration, in other words, when the systems that help the API to work are not updated frequently enough or when they are not tuned to implement security best practices, this threat becomes a reality for the API.

It is quite important to manage the whole environment where the API runs, including endpoints, underlying systems, libraries, and so on. APIs, as is the case for any software, have versions that are eventually made obsolete. Endpoints running deprecated versions should either be decommissioned or made unavailable. When improper inventory management occurs, forgotten API endpoints or sustaining systems may still be participating in the API’s current implementation and expose additional exploitable vulnerabilities. The API you developed is meant to be consumed by valid users or third parties. However, investment in protecting APIs is usually dedicated more to external users than to partners. When an attacker discovers API integrations, they might try to exploit the third party to then intrude on the originally targeted endpoint. This is referred to as the unsafe consumption of APIs and can be avoided or at least reduced when you adopt a terminology called zero trust, which we will talk about later.