In the fast-paced and ever-growing digital world, APIs are everywhere, acting as bridges to allow communication between software applications and systems.  However, with these bridges come risks: API vulnerabilities. These vulnerabilities do pose a threat to security and, left unchecked, can have significant repercussions. In this article we will examine what an API actually is, and what some of the common vulnerabilities can be.

API stands for Application Programming Interface. In essence, it is a set of rules and tools that allow communication between different pieces of software, defining the ways developers can request information or perform tasks between different software tools. This can be done regardless of the coding language used of the service being called or the one being used, because the API has defined both what can be asked for and how it can be asked. In essence, imagine it as an interpreter allowing two people to speak to each other even though they do not speak the same language.

As with all technological improvements, a poor implementation of an API can cause many issues. Not only limited to sub-par performance, it can also expose the service to security risks. Below is a list of some of the most common API vulnerabilities to consider.

Broken Object Level Authorisation

When using APIs, there are places called endpoints that deal with identifying things like objects. It can be risky if an API takes a user input and uses it to access a location holding data, as it can create more avenues for attack. There should be checks in place to ensure a user needs to access these areas before allowing them to do so. For example, a bad actor could try to manipulate the user ID in an API call to impersonate another user; if additional checks are not in place they could access data that does not belong to them.

Broken Authentication

Sometimes, the way systems check if someone is who they say they are, isn't done correctly. This can let attackers get hold of special codes that prove someone's identity, or find mistakes in how the checks are done to pretend to be someone else. When this happens, it means the system's ability to tell who's using it isn't reliable, which makes the whole system less secure. For example, if the API doesn't correctly check 'session tokens' (a piece of data that identifies a 'session - a related exchange of data) then a bad actor could use a stolen session token to impersonate someone.

Broken Object Property Level Authorization

Broken object property level authorization in an API means that the system doesn't properly control who can access specific parts of the data it provides. For example, if an API for a messaging app is broken, someone might be able to see other users' private messages even if they're not supposed to. It's like if the security gates in a building were malfunctioning, allowing people to enter restricted areas without proper permission.

Unrestricted Resource Consumption

In simple terms, unrestricted resource consumption means that the API does not limit the amount of times that someone can try to use it. This can result in too many requests being sent to a service resulting in it slowing down, or even crashing completely. Proper implementation will consider adding limits to prevent this (which is why you may see messages such as "too many attempts, please wait 30 seconds" when trying to do something within an app). If an API allows unrestricted resource consumption it can be vulnerable to DDOS (distributed denial of service) attacks where a bad actor floods it with requests, rendering it completely unusable.

Broken Function Level Authorization

Function Level Authorization are rules in place to check if a user has permission to carry out certain actions or use certain functions. If it is not properly implemented then it might allow users to do things they are not supposed to do (for example allowing someone to delete somebody else's images on a photo-sharing platform). A bad actor might exploit broken function level authorisation by carrying out administrator level actions which they should not be able to do.

Unrestricted Access to Sensitive Business Flows

At a basic level, Unrestricted Access to Sensitive Business Flows means that anyone can access or use key parts of a business' operations without any control over what they are doing being put in place. Whilst this is not necessarily an API-specific risk, APIs can enlarge the risk surface. For example, a bad actor might exploit unrestricted access to buy up all the stock of a highly anticipated item in order to later resell it at a higher price.

Server-Side Request Forgery

Server-side request forgery (SSRF) is when a bad actor manipulates a server into accessing resources that they should not have access to, due to a lack of checks in place. For example, a bad actor may use SSRF to access a sensitive file that is usually protected behind a firewall, because the service has not checked what it is being asked to deliver.

Security Misconfiguration

APIs (and their underlying systems) often have various configurable functions or settings (in order to make them more customisable). Unfortunately, this can result in security settings being configured incorrectly (or even not even set up) which can make them vulnerable to multiple attack vectors. In simpler terms, it is like having a door with three locks on - but forgetting to lock them.

Improper Inventory Management

As APIs can connect to many different services, it is important to ensure that all the connected services and tools are also up to date (inventory management). A bad actor might be able to gain access because one of the services is using an out-of-date protocol with known vulnerabilities.

Unsafe Consumption of APIs

Developers have come to rely on, and trust, APIs as a resource. This can result in them not necessarily using the strongest security protocols when connecting to APIs. Bad actors take advantage of this by targeting 3rd party services to compromise the API, rather than the API itself.

Ultimately, APIs are incredibly useful tools that we rely on constantly in everyday life. However, as with all technological implementations, if they are improperly implemented then there is a very real risk that they can, and will, be exploited. Therefore, it is vitally important to consider the security implications when implementing an API within your toolset.

Resources

OWASP API Security Project: https://owasp.org/www-project-api-security/

Red Hat: What is an API?: https://www.redhat.com/en/topics/api/what-are-application-programming-interfaces

The information contained in this article is provided for informational purposes only and does not constitute professional advice and is not guaranteed to be accurate, complete, reliable, current or error-free.