OWASP Top 10 API Security Risks: how to secure APIs in 2024

The OWASP foundation published its last update of the Top 10 API Security Risks in 2023, but threats to our API ecosystems haven’t stopped evolving since then. We’re sharing an overview of each vulnerability, what it means for your organization, and how it affects the way you secure APIs in 2024.

While counting down the list, we’ll include mitigations and features that can supplement mitigations by leveraging Axway’s Amplify Platform to address each risk.

API Security Tools and Best Practices

API 10: Unsafe Consumption of APIs

The problem

Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. Attackers go after integrated third-party services instead of trying to compromise the target API directly. Then, when the target API uses those third-party services, it is exploited through its weak security-checking approach.

For example, you want to use well-known third-party APIs to enhance your service. But when it is a well-known company, you tend to skip some security-related steps, like proper response parameters check, establishing allowable redirect URLs, limiting resource allocation, etc.

First, attackers can use third-party APIs to store some malicious code as a business object, and then invoke your API to access that object. If you don’t check the incoming data, the malicious code may be executed on your system, causing data exfiltration.

What can be done

You should apply the same security checks and verification steps as you do for any unknown API client:

• Headers and input parameter validation
• Using a secure communication channel
• Using rate limiting, API throttling, and proper timeouts
• Setting a list of allowable URL redirects

Make sure that you monitor API usage to detect any unplanned API consumption spikes or unusual API usage patterns.

API 9: Improper Inventory Management

Working our way up the list, I can’t imagine number 9 ever featuring on the OWASP Top 10 because, in the application world, it’s quite unique to APIs. This is kind of a knock-on effect from how teams are delivering software. When you have multiple deployments, and you add a lack of proper documentation and API decommission strategy, you end up with forgotten APIs in the form of both old and shadow APIs.

The problem

You’ve been building APIs for some time now and they meet all your security processes and pass all your testing. However, you haven’t properly deprecated/removed old API versions or have untracked and/or undocumented APIs that have slipped through your net.

In most cases, attackers take advantage of the weakest link in your system, and these old, exposed APIs are ripe for the picking.

The first thing an attacker is going to do when they see your API version is /v3 is to try /v1 to see if the security mechanisms in place for /v3 also apply to /v1. Often, they don’t, and the attacker has got their foot into your enterprise.

Also, undocumented or poorly documented APIs don’t provide good visibility into what data is shared in an API response. An API often returns more data than needed, creating a data leak.

What can be done

The first thing you should do is perform an inventory of all your API hosts and document everything:

• What stage the APIs are in (production, staging, test, development) and who has access to them
• Data flows with full visibility into what data is returned
• Protection mechanisms, CORS policy, and rate-limiting

Next, you need to have a test backend, so your non-production environments are connected to this test backend (non-production data).

Adopt and document an API retiring policy. Implement this policy as a DevOps pipeline. Automating as many steps in your API lifecycle as possible gives you an error-free approach to preventing old API versions from being still in use.

Establish a federated view of all your APIs across all environments. This will help you to have full visibility into the state of your APIs and take necessary action promptly.

With Axway’s Amplify Platform you can:

• Track APIs within the API unified catalog which will list the APIs from all your API gateways (regardless of different vendors). Here you can view the documentation, stage, and test the APIs.
• API endpoints can be deprecated using an API manager which will render them inaccessible.
• Thanks to the monitoring and analytical tooling, you can see which APIs are being used, which could lead to the discovery of undocumented APIs.

See also: From Zombies to Legacy or Shadow APIs, it’s time to remediate your lost APIs

API 8: Security Misconfiguration

Just about aligned with the OWASP Top 10 we’ve got security misconfiguration, but it’s a slightly different beast as the sole focus is misconfigured APIs. The adoption of SaaS technologies pushes the responsibility for many configurations onto the SaaS providers.

The problem

Attackers will try to find out as much about your API management solution as possible. They apply different techniques, for example, forcing error messages that include stack traces, or trying to find unpatched or unprotected endpoints or insecure directory access.

Attackers often look up the exposed information against the CVE database. These are publicly available and sometimes even come with a proof-of-concept (PoC) exploit.

There is no doubt that your unpatched flaws will be exploited. They’ll also look for:

• Features that are poorly configured like unnecessary HTTP verbs
• A possibility of sending requests over an untrusted channel like HTTP or a deprecated secure channel like TLS with CBC-mode cipher suites
• Lack of security headers configured in HTTP responses

What can be done

This vulnerability covers the entire space of API management: from configuring your API gateway to properly developing your API specification and establishing rigorous testing procedures.

In general, the recommended set of actions can be split into two large areas:

• Configuring your HTTP requests processing chain and performing periodic checks, similarly to how pilots do their pre-flight checks
• Automating as much as possible in your API lifecycle: deploying to API gateway and configuring security, running security tests with every deployment, etc.

It is hard to provide all-inclusive recommendations here because of the scope. However, there are some coarse grain recommendations:

• Always use the latest TLS version with all security patches installed
• Establish a company-wide standard on what type of request and response data formats are allowed. Then, create and maintain global policies that perform necessary checks.For example, an inbound security policy may check for allowable HTTP verbs and payload scanning, and the outbound global policy should capture all unmanaged errors, provide meaningful response messages, and remove any error stack.
• APIs accessed through browser-based clients should implement a CORS policy and get checked for required headers.

There is a myriad of things you should be doing here, and we strongly recommended staying up-to-date with OWASP’s recommendations. To help with mitigation and add an extra layer of defense, Axway’s Amplify Platform can help:

• Overwrite error messages generated by the backend using either redacting or error handlers
• Check for and change HTTP Headers and CORS settings

API 7: Server-Side Request Forgery

Compared to the previous vulnerability, server-side request forgery is easier to understand and prevent.

The problem

Server-side request forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URL. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.

In today’s interconnected world, with the ubiquitous influence of social networking, app developers are often pushed to let their apps access other resources on the network, such as uploading pictures, resumes, or other files from social networks.

This opens a door to SSRF, where a bad actor provides a malicious URL as part of a resource location or initiates a port scanning from within an internal network.

What can be done

It is easier to handle this threat for apps that have a limited and well-known set of possible resource locations. In this case, customers can configure their API management solution to check URLs against well-known locations.

It is more difficult if a client is allowed to supply any URL as part of the request. In either case, APIs must apply the recommended checks:

• Use a solid URL parser
• Validate and sanitize all incoming requests
• Do not send a raw response from a remote URL
• Prevent HTTP redirects
• If possible, use known schemas and ports
• Block any request on the internal networks

API 6: Unrestricted Access to Sensitive Business Flows

This flaw is not technical. It doesn’t break the security of your infrastructure servers. However, it may cause losses to your business.

The problem

APIs vulnerable to this risk expose a business flow – such as buying a ticket, or posting a comment – without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn’t necessarily come from implementation bugs.

The OWASP Web site provides good examples where bad actors can overuse some business-critical APIs to their advantage.

For example, imagine a hacker wants to fly to a specific destination. If he can find an airline that doesn’t charge cancelation fees, he can automate booking most of the tickets. Then, a day or two before flight data, he can cancel all these tickets. Having so many unsold tickets, the airline company will discount the price. The bad actor will buy a ticket with a discount.

What can be done

Business and API developers should establish these critical APIs for the business, then apply some or all of these techniques:

• Inject human detection mechanisms, like reCAPTCHA or biometric solutions
• Detect non-human patterns in using your APIs, like add-to-cart and purchase options in less than a second
• Identifying unexpected client devices, like headless browsers

API 5: Broken Function Level Authorization

The current OWASP Top 10 features three authorization type issues: functional level, object property, and object level authorization. The previous iteration of the OWASP Top 10 in 2019 had two of these flaws, which makes authorization vulnerabilities very important to address.

We’ll get to the other issues of object-level authorization later, but with broken functional-level authorization, it comes down to users having access to APIs they simply shouldn’t be authorized to access.

These could be admin APIs open to non-admin users, or clients who may have access to data manipulation beyond the desirable level (like creating or deleting an object).

This flaw is much more common with APIs, as it is often easy to predict an API endpoint once you know one or more API endpoints in use in the application, as well as the fact that there is a reliance on the UI to secure restricted functions.

The problem

An attacker will try to map out your APIs in various ways to send a successful request to one endpoint that they should not have access to. The complexity of modern applications, with their many roles and groups, means the application may not prevent the attacker from sending a request to a seemingly restricted endpoint and having the endpoint process their request.

There’s potential that an attacker could carry out an administrative functionality such as deleting users, listing all the users, shutting down services, etc.

For example, an app can call an API to show your user’s details: GET /api/users/{id}. An attacker can try to craft a request to create a new user: POST /api/users and send a body with a parameter {"role":"admin"}.

If your functional level authorization is broken (e.g. not blocking calls to the POST method), the attacker can create a new user with admin capabilities and get access to what she is not authorized to.

What can be done

Firstly, keep in mind that you don’t make an endpoint hidden just because it is not documented. So, as the first measure, your solution should have a “deny all” default policy. That will make your API developers and administrators explicitly assign correct roles to access those APIs.

If your admin APIs are accessed only by internal people, then you need to block access to these APIs from outside of your network.

Your API management solution should have an easy way to assign users and groups to each API, or API method and have an easy way to verify this.

As recommended in the OWASP API Security Top 10, Amplify can help you because:

• It has a “deny all” default policy
• It can differentiate between many roles and groups such as policy developer, gateway admin, API developer, end-user, etc.
• Endpoint access can be determined by a combination of organization and application

See also: How to easily secure your APIs with API keys and OAuth

API 4: Unrestricted Resource Consumption

This issue only appears on the API Security Top 10 but again does not mean traditional applications don’t suffer from this issue as it’s pretty much self-explanatory. Simply put, a resource provider doesn’t put restrictions on its solution for using infrastructure resources.

The problem

Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations and paid for per request.

Successful attacks can lead to Denial of Service or an increase in operational costs. So, this vulnerability doesn’t expose internal data to an attacker, but rather causes losses to the business (either through very high resource consumption or DoS).

An attacker launches an attack through your APIs in an attempt to force your service to fall over by over-consuming network, CPU, memory, and/or storage resources. Bear in mind this could be done inadvertently by a valid user if any of the following limits are missing or set inappropriately:

• Execution timeouts
• Max allocatable memory
• Number of file descriptors
• Number of processes
• Request payload size (e.g. uploads)
• Number of requests per client/resource
• Number of records per page to return in a single request-response

What can be done

First of all, your personnel responsible for configuring an API management solution should know and understand this issue and its possible resolution. It is better to implement your configuration right from the start.

However, in any case, you should have test tooling and suites to analyze your API protection by crafting and executing API requests where you simulate a possible attacker’s actions: send very large files, generating too many requests from one client in a short period, analyze response codes and times, etc. This testing will pinpoint vulnerable APIs.

Amplify can help you to tackle this flaw with its ability to configure:

• Quota operation-based user identity
• Rate Limiting (Floating Time Window, Smooth Rate Limiting) protection
• Message size checks and anti-virus/ICAP scanning for payloads
• Many built-in values for timeouts, payload size, etc. that are present to reasonable values

API 3: Broken Object Property Level Authorization

This category combines API3:2019 Excessive Data Exposure and API6:2019 – Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.

Another new entry not seen over on the OWASP Top 10, this risk is due to processing being done on the client side. This occurs when there is one endpoint that is consumed by multiple clients where there is a reliance on the front-end engineers to filter out the data being returned by the API.

It’s a poor design choice that could be caught at the design phase and during a threat model where the issue is an API exposing private data. This is comparable to the bad practice of SELECT * where there is a certain amount of laziness and oversight.

The problem

A user is pulling information about themselves from your application where their client calls the API

api/v3/users/me

The payload that is sent from the client to the server is

{“username”:”axway”,”join_date”:”2024-06-12″}

The attacker has done some recon and learns that this same call to pull information about a user has an internal property to elevate the user’s rights. The same API is called by the attacker, api/v3/users/me, but they now include an extra parameter in their payload:

{“username”:”axway”,”join_date”:” 2024-06-12″, “is_admin”:”true”}

This is a valid request, but this is an internal property that clients shouldn’t have access to. The attacker has circumnavigated the authorization mechanisms because the framework automatically binds input from the client.

The attacker has successfully granted themselves admin access to your system by exploiting a mass assignment vulnerability.

These types of issues are very dependent on the business logic of an application, but using this technique an attacker could manipulate requests to perform many actions which could include adding money to their balance or injecting attacks against the underlying system.

A simpler use case is where an API returns properties of an object that are considered protected or private.

What can be done

Always address this type of issue at the root cause, which is in code and/or configuration. Test your APIs against expected input and/or output.

You should:

• Analyze any functions that bind a client’s input to code and adopt an explicit assignment approach where you specify what properties are returned to a client
• Use parameters validation for requests and object schema validation for responses to make sure that you accept and return only business-approved properties
• Allow exposure only to the object properties to which a client has authorization

API 2: Broken Authentication

We’re aligned once more with the OWASP Top 10 but unlike traditional applications, API authentication can be more complex than your traditional web app authentication.

Like traditional applications, it’s usually exposed to everyone and often publicly. Included in this is both forgot password and reset password functionality which can be overlooked.

These endpoints responsible for authentication should be treated differently from other endpoints with extra care taken. Authentication mechanisms should differ according to the type of application e.g. a web application vs an IoT client.

The problem

Attackers will try to gain access to your application by tinkering with its authentication mechanisms by either circumnavigating the authentication mechanism itself or by going after the users of your system. By going after the users of a system, an attacker affects the integrity of the system by becoming those users.

The most basic attack used to exploit broken authentication is brute-forcing credentials and MFA codes.

For example, when trying to reset a password a user will receive a 5-digit code to their mobile device. If there is no lockout or throttling mechanism for this function the attacker could successfully brute force the MFA code.

Another example would be a function to change a user’s password without re-entering the user’s existing password. An attacker can still an authentication token and update that user’s password consequently taking over that user’s account.

What can be done

The first thing to do is to understand your current authentication mechanisms and the flows to the authentication API bearing in mind OAuth and API keys are not authentications.

With anything like this, don’t roll on your own and always rely on proven technologies. Please see various guides from OWASP, mainly the authentication guide. With Amplify Platform, you can:

• Integrate with current authentication technologies e.g. LDAP, CA SiteMinder, IBM Tivoli Access Manager, RSA Access Manager, Oracle Access Manager, etc.
• Use Rate Limiting (Floating Time Window, Smooth Rate Limiting) protection
• Utilize threat detection built into the products that can alert and prevent malicious requests.
• Utilize a web application firewall (WAF)

API 1: Broken Object Level Authorization (BOLA)

At the top of the list is the one you should focus most of your attention on. It is actually much like that one couple you know who often breaks up and gets back together. This risk has that “complicated” relationship with API 5: Broken Functional Level Authorization, as they can be separated or together depending on what list you’re referencing. But here it is separate with the intention being to put more focus on broken object-level authorization.

The problem

BOLA is essentially based on IDs and the erroneous ways they are tied to authorization. Secure systems should have authorization checks that rely on user policies and hierarchies where it checks if the user logged in has access to a requested object.

Unfortunately, in API-based applications the server doesn’t always track the client’s state fully, so there is this reliance on object IDs.

Attackers, once they see that your application is using IDs, will try to enumerate them. For example, you can retrieve your user data by calling

api/v2/user/40404

The attacker decides to cycle through IDs such as

api/v2/user/001

api/v2/user/002

and so on. To the attackers’ delight, the application will return data about those users. Digging deeper, the attacker could gain access to admin functionality, etc.

What can be done

There is a tendency to use GUID instead of guessable IDs, and although it offers obscurity and should be used, it is not a complete solution. Good authorization is business-dependent, and every application should be analyzed before implementing authorization.

The right solution should be selected based on the technologies and architecture where every controller adopts the authorization put in place.

There is a tendency to also put server-side access controls in place at the functional level, which only addresses the risk outlined in API 5: Broken Functional Level Authorization and stops there.

This means there are no checks at the data or object layer which should protect against tampering with IDs in requests. So, enforcing the server-side authorization checks against the data layer access control should be done by verifying that the current user is allowed access to the requested data.

Within Axway’s API Gateway, you can take a two-step approach to tackle both authorization issues of API 1 BOLA and API 5 BFLA. There are many ways of integrating authorization mechanisms, such as:

• RSA Access Manager authorization
• Attribute authorization
• Axway PassPort authorization
• CA SOA Security Manager authorization
• Certificate attribute authorization
• Entrust GetAccess authorization
• Insert SAML authorization assertion
• LDAP attribute authorization
• SAML authorization
• SAML PDP authorization
• Tivoli authorization
• XACML PEP authorization

For example, to specifically tackle the BOLA issue, administrators could:

• Use an XACML PEP filter that enables them to configure the API gateway to act as a Policy Enforcement Point (PEP). The API Gateway intercepts a user request to a resource and enforces the decision from the Policy Decision Point (PDP)
• Utilize JWT tokens which contain the user identity, attributes, and roles that can be generated by API Gateway. The backend API will be responsible for performing the authorization check or delegating to a policy engine.

And that’s a wrap

The OWASP API Security Top 10 is an acknowledgment that the game changes when you go from developing a traditional application to an API-based application. The list is a reshuffle and a re-prioritization from a much bigger pool of risks.

Axway’s Amplify Platform is one of the many tools that can help you reduce the risks featured in API Security Top 10.

Amplify lets you govern, secure, and monitor APIs on-premises and in multiple clouds from a central location while giving development teams the freedom to use the tools that work best for them without worrying about using unsanctioned solutions.

Amplify platform will help you enforce security policy at the gateway and easily find and secure unmanaged APIs. We’ll help you implement an API strategy that incorporates security from the very beginning.