OWASP API Security Top 10

The OWASP API Security Top 10 highlights the top vulnerabilities in application programming interfaces

Few acronyms are more relevant to explain the digitization of our world than API. Behind these three letters lies the concept of Application Programming Interfaces. These application programming interfaces are specifications or rules that facilitate communication between different applications. APIs define and protocolize how one software interacts with another. As a result, APIs have become vital elements in developing new software and the connection between applications.

The role of APIs in the development world has attracted cybercriminals, making them the target of attacks. This is why the OWASP Foundation, a global benchmark in developing cybersecurity materials and standards, published 2019 the first version of the API Security Top 10, focused on listing the 10 significant vulnerabilities that can be present in APIs and exploited by hostile actors.

In early June 2023, the new version of the OWASP API Security Top 10 was released, incorporating all the changes that have occurred in the last four years around APIs and threats that developers, cybersecurity specialists, and companies should be aware of.

Below, we’ll break down the key takeaways from the 2023 version of the OWASP API Security Top 10 and how this ranking can help you protect APIs throughout their lifecycle.

1. APIs, a key element in the digitization of the world

We live surrounded by APIs, even though they are out of sight. APIs make it possible for us to pay for an e-commerce purchase, to have weather information at our disposal in an app on our mobile phone, or to book a hotel room for a weekend getaway with our partner at the click of a button.

The definition of APIs with which we began this article shows their relevance in software development following the leap to the cloud and the rise of software as a service (SaaS), mobile apps, and IoT devices.

In fact, APIs have revolutionized the development of applications by reducing costs and the time needed to develop them. Thanks to APIs, there is no need to create software from scratch, and the capacity for innovation and scalability is increased.

Today, APIs are used in business applications in all kinds of economic sectors (finance, transport, commerce, health), whether they are developed for use by customers, business partners, or internally.

By facilitating communication between applications and data transmission, APIs have become a priority target for criminals seeking to commit malicious actions against business software and achieve their criminal objectives: theft, hijacking, data exfiltration, paralyzing a company’s operations, etc.

The detection of vulnerabilities related to insecure APIs has become a matter of vital importance for companies today. This is why implementing a web security audit is essential to find weaknesses in APIs before hostile actors exploit them.

2. Top 10 API Security Risks

As with the other OWASP rankings, the API Security Top 10 results from extensive research into API security incidents and input from experts worldwide. The goal of the new API Security Top 10 version is to list specific API risks that companies, developers, and cybersecurity professionals should consider to strengthen their security.

As such, the API Security Top 10 is not exclusive of other OWASP documents, such as the Top 10 Web Application Vulnerabilities. Applications that use APIs may have vulnerabilities directly linked to them, but they are also susceptible to some of the generic weaknesses in the Top 10 web application vulnerabilities.

In addressing each of the top risks, OWASP provides:

A description of the risk
Examples of scenarios in which hostile actors can exploit the vulnerability
Recommendations for preventing their presence in APIs

This API Security Top 10 is composed of the following risks:

Broken authorization at object level
Improper authentication
Broken authorization at the object property level
Unrestricted resource consumption
Broken authorization at the function level
Unrestricted access to sensitive business flows
Server-side request forgery
Incorrect security configuration
Inadequate inventory management
Insecure API consumption

2.1. Broken object-level authorization

Object-level authorization is an essential mechanism in the operation of APIs, as it controls user access and verifies that each user has the necessary permissions to perform a given action on the requested object.

Thus, each API endpoint that receives an object ID and performs an action on it must carry out a check to ensure authorization at the object level.

What happens if this mechanism fails? Information disclosure can occur and open the door to data manipulation and destruction.

OWASP points out that this vulnerability is easily exploitable by hostile actors. Criminals can exploit API endpoints with this weakness. This problem is widespread in API-based applications, hence its first position in the API Security Top 10.

2.1.1. Prevention

To prevent this vulnerability, the OWASP API Security Top 10 recommends:

Implement a proper authorization mechanism based on policy and user hierarchy.
Use the authorization mechanism to check whether the authenticated user has access to perform the requested action for each function that uses a client data entry to access a database record.
Prioritize using random and unpredictable values such as GUIDs for record identifiers.
Include verification tests to evaluate possible vulnerabilities of the authorization mechanism and do not include changes that cause such tests to fail.

At Tarlogic, we recommend applying a default most minor privilege policy to implement authorization controls. It is also interesting to remove any client-side parameters related to the user’s identity or permissions, as this information should always be obtained from the server side based on the active session.

2.2. Incorrect authentication

Authentication endpoints are crucial assets, so protecting them against malicious activity is essential. OWASP cites several scenarios in which an API is vulnerable concerning authentication:

Credentials are allowed to be entered when the attacker employs brute force with a list of valid usernames and passwords.
Brute-force attacks on the same user account are possible without having an account-locking mechanism.
Weak or unencrypted passwords can be used.
Sensitive authentication data such as tokens or passwords are sent in the URL.
Users can change their email or password or perform sensitive operations without being required to confirm by entering a password.
Weak encryption keys are used.
Tokens are not validated for authenticity.
Accepts unsigned and/or unencrypted JWT tokens.
JWT token expiry time is not validated.
Storage of keys in plain text, weak or without hashing.
Use of weak encryption keys.

The OWASP working group that compiled the API Security Top 10 argues that authentication mechanisms are easy targets for hostile actors, as they are exposed and tools exist to facilitate exploitation. Furthermore, OWASP warns of the technical impact of this vulnerability, as it allows criminals to gain complete control of other users’ accounts, access their private data, and impersonate them to carry out sensitive actions.

2.2.1. Prevention

The API Security Top 10 proposes several actions that can be implemented to prevent this vulnerability:

Accurately understand all API authentication flows.
Analyze all authentication mechanisms.
Use existing standards when managing authentication, token generation, and password storage.
Forgotten password and credential recovery endpoints should be managed, like login endpoints, in terms of brute force, rate limiting, and lockout protections.
Require two-factor authentication for sensitive operations.
Opt for multi-factor authentication whenever possible.
Put in place mechanisms against brute-force attacks and credential input.
Have account lockout mechanisms in place to prevent attacks against users.
Perform weak password checks.
API keys should only be used for API client authentication, not for user authentication.

2.3. Broken Authorization at the Object Property Level

The OWASP API Security Top 10 states that an API is vulnerable when a user can access an object using an API endpoint without validating that the user has the right to access the specific target properties he wants to access.

Thus, the API endpoint is vulnerable if:

It exposes properties of an object that are considered sensitive and should not be accessed by the user.
Allows the user to change, add, and remove the value of a sensitive property they should not have access to.

Many APIs expose endpoints that return all object properties. In addition, automated tools exist to identify properties that can be manipulated. Exploiting this vulnerability can be used to access, steal, and corrupt data. In some cases, unauthorized access to object properties can be used by hostile actors to escalate privileges and take control of the account.

2.3.1. Prevention

To avoid this vulnerability, OWASP recommends:

If exposing an object using an API endpoint, always check whether the user should be able to access the properties of the object being exposed.
Avoid generic methods and select the specific properties you want to return.
Avoid using functions that automatically bind client data to code variables, internal objects, or object properties.
Only allow changes to object properties that need to be updated by the client.
Implement response validation mechanisms.
Keep returned data structures to a minimum, depending on business needs and objectives.

2.4. Unconstrained resource consumption

APIs must satisfy multiple requests and use resources such as bandwidth, memory, or storage. If resource consumption is not limited, two scenarios can occur:

The exploitation of this vulnerability by hostile actors through a denial of service (DoS) attack, given the lack of sufficient resources to service all requests made to the API.
A substantial increase in operational costs is associated with increased resources, e.g., more cloud storage.

Exploiting the lack of limits on resource consumption is easily exploitable, as only API requests need to be made. Criminals have automated tools to perform DoS attacks through high-traffic loads.

The OWASP API Security Top 10 considers that it is essential to set appropriate limits regarding execution timeout, maximum memory that can be allocated, maximum number of processes, or maximum uploaded file size.

2.4.1. Prevention

To prevent this API vulnerability, OWASP recommends:

Have a solution in place that limits memory, CPU, number of restarts, open file descriptors, and processes such as containers or lambda functions in serverless infrastructures.
Set a maximum data size on all incoming parameters—for example, the maximum number of elements in arrays or the total length of upload files.
Stipulate a limit on how often a client can interact with the API.
Ensure that rate limiting is in line with business needs and objectives.
Limit the number of times or the frequency with which a single API user can execute a single operation.
Add server-side validation for parameters primarily related to the number of records returned.
Configure spending limits for all service providers or set up billing alerts.

2.5. Broken authorization at the function level

The fifth API Security Top 10 position is occupied by broken authorization at the function level. To detect this kind of problem, OWASP argues that an in-depth analysis of the authorization mechanism has to be carried out, taking into account the hierarchy of users and existing roles and groups.

This analysis aims to find out whether:

An average user can access administrative endpoints.
A user can perform sensitive actions by changing the HTTP method despite not having access.
A user in a particular group can access a function that should only be accessible to users in another group because he was able to guess the endpoint URL and parameters.

By exploiting this vulnerability, hostile actors can access unauthorized functions, mainly administrative ones. Beyond the exfiltration, deletion, and corruption of data, attackers can even disrupt the service with severe economic consequences.

2.5.1. Prevention

The OWASP API Security Top 10 emphasizes that the best way to prevent this vulnerability is to have a consistent and easily analyzable authorization module. The authorization mechanism should deny access by default and make explicit grants to specific users to access each function.

In addition, this document recommends reviewing API endpoints for authorization flaws at the role level, always considering business objectives. It is also essential to ensure that:

All administrative controllers perform authorization checks based on each user’s group and role.
Administrative functions within a regular controller also implement authorization checks based on the group and role of the users.

2.6. Unrestricted access to sensitive business flows

OWASP points out that when you create an API endpoint, you expose a business flow, and it is critical to understand that some business flows are more sensitive than others. Excessive access to them can be detrimental to the business.

What business flows are we talking about? Examples of such flows could be a product purchase flow, a feedback flow, or a booking flow.

When is the API endpoint considered vulnerable? When it exposes a sensitive business flow without having mechanisms in place to restrict access adequately.

Hostile actors need to understand the business model supported by the API to seek out the most sensitive business flows and attempt to access them to damage the business.

The impact of exploiting this vulnerability is not technical. Still, it can be very damaging to the business, affecting its activity, e.g., preventing legitimate consumers from buying a product or making a reservation because an attacker has been able to deplete the stock through an automated process.

2.6.1. Prevention

Mitigation of this vulnerability should be undertaken from both a business and engineering perspective to protect business flows and address weaknesses.

OWASP recommends to address automated threats successfully:

Implement device fingerprinting. Deny service to unexpected client devices.
Improve human detection using captchas or biometrics.
Detect non-human patterns by studying user flow.
Block IP addresses of known Tor exit nodes and proxies.
Protect and limit access to APIs directly consumed by machines.

2.7. Server-side request forgery

The OWASP document notes that server-side request forgery problems occur when an API connects to a remote resource without validating the URL provided by the user. In this way, the hostile actor coerces the application into sending a manipulated request to an unexpected destination.

To exploit this vulnerability, attackers must find an API endpoint that accesses a client-supplied URL. What does the exploit achieve? An enumeration of internal services, obtaining information, or bypassing firewalls and other security mechanisms can be performed as the attacker takes advantage of the server’s privileged position in the infrastructure to force arbitrary requests.

The API Security Top 10 also warns that, in some cases, the exploitation of this vulnerability can allow DoS attacks to be launched or open the door for the server to be used as a proxy to hide other malicious actions.

2.7.1. Prevention

To avoid this kind of problem, OWASP recommends:

Isolate the mechanism for obtaining resources on the network.
Establish allow lists:
Remote sources from which users can download resources.
URL and port schemes.
Media that are accepted for a particular functionality.
Disable HTTP redirects.
Use a URL parser to avoid inconsistencies in your parsing.
Validate and sanitize input data provided by clients.
Do not send raw responses.

2.8. Incorrect security configuration

What does it mean if an API has an incorrect security configuration? According to the OWASP API Security Top 10, this situation occurs when:

The API needs to be secured correctly throughout its stack, or there are misconfigured permissions on the cloud services.
The latest security patches need to be included, or systems need to be updated.
Unnecessary functions are enabled.
There are discrepancies in how servers process incoming requests in the HTTP server chain.
Transport Layer Security (TLS) is missing.
Failure to send security or cache control policies to API clients.
Either there is no cross-origin resource-sharing policy, or the cross-origin resource-sharing policy is not configured correctly.
Error messages expose sensitive information.

OWASP warns that cybercriminals are trying to exploit all these unaddressed flaws. In addition, security configuration problems can occur at any API level. They can not only be used to expose sensitive data about software users, but hostile actors can also compromise the server.

2.8.1. Prevention

To prevent problems related to API security misconfiguration, it is essential to protect the API throughout its lifecycle:

Implement a hardening process in the deployment lifecycle, which implements an adequately hardened environment.
Review and update API configurations, including orchestration files, components, and cloud services.
Automate configuration assessment and tuning across all environments so that such analysis can be performed on an ongoing basis.

2.9. Inadequate inventory management

The second-to-last spot in the API Security Top 10 is inventory management. Not only do companies need to know their APIs precisely, but they also need to know how APIs store data from or share information with third parties. Otherwise, they can run into two types of blind spots:

Documentation blind spot. You do not know, for example, in which environment an API is running or which version it is running, nor do you have an inventory of the host or the one that exists needs to be updated.
Data flow blind spot. The API shares sensitive data with a third party without business justification or approval. There needs to be an inventory of the data flow or deep visibility into what sensitive data is shared.

Inventorying sensitive data flows is essential in responding to an incident on the side of a third party.

2.9.1. Prevention

The OWASP API Security Top 10 recommends organizations:

Inventory all API hosts, detailing the API environment, version, and who has network access to the host.
Inventory the embedded services, indicating their role in the system, their data flow, and their level of sensitivity.
Document all aspects of the API: authentication, errors, redirections, and rate limit.
Automate the generation of documentation through the use of standards.
Documentation must be available to those authorized to use it.
Have cybersecurity services to protect all exposed versions of an API.
Do not use production data with non-production API deployments.
If security enhancements are incorporated into new versions of an API, perform a risk analysis and report on the measures to be taken concerning previous versions. They are establishing whether these measures can be implemented or whether customers should instead leapfrog to the latest version.

2.10. Insecure API consumption

Many developers tend to rely on third-party APIs, especially if the providers are well-known companies with a proven track record. This means that the security standards they adopt are weaker in critical areas such as authentication, authorization, transport security, or input validation. This point relates to supply chain security management.

The vulnerability of insecure API consumption manifests itself when:

An API interacts with other APIs through an unencrypted channel.
Data obtained from other APIs are not validated and sanitized before being processed and passed to API components.
Redirects are blindly followed.
Failure to limit the resources that can be used to process responses from third-party services.
No timeouts are implemented for interactions with third-party services.

OWASP emphasizes that to exploit this vulnerability, hostile actors need to know which APIs the target API is integrated with and even compromise them. If exploitation is successful, criminals can obtain sensitive information and execute injection and DoS attacks.

2.10.1. Prevention

The OWASP ranking proposes three actions to prevent problems linked to insecure consumption of other APIs:

Consider the security strategy concerning service providers’ APIs.
Take measures to ensure API interactions are conducted over a secure communication channel (TLS). Data received via other APIs should be validated and sanitized before being used.
Refrain from blindly following redirects, but have a list of known locations to which embedded APIs can redirect to the organization’s API.

3. API Security Top 10 shows the importance of security audits

Throughout the previous section, we not only listed the principal vulnerabilities that developers and organizations with APIs have to deal with but also made reference to the measures that can be put in place to strengthen these critical assets of an IT infrastructure.

All of the measures in the OWASP API Security Top 10 highlight the importance of organizations conducting web security audits that continuously scan APIs to identify vulnerabilities and mitigate them before hostile actors and security incidents exploit them.

The web security audit provided by Tarlogic Security professionals serves to:

Identify vulnerabilities related to web server infrastructure.
Detect application vulnerabilities, verifying all kinds of injections and techniques at their entry points.
Perform specific security tests for multiple types of assets, including APIs.
Identify vulnerabilities related to the use of software and the business logic of the application.

In short, APIs have revolutionized application development, reducing lead times, lowering costs, and facilitating the production of scalable and flexible software. This is why they currently play a central role in digitizing people’s and companies’ lives.

This centrality has made them a priority target for many cybercriminal groups. Hence, initiatives such as the OWASP API Security Top 10 seek to contribute to a more secure API ecosystem, making the actions of hostile actors more difficult and protecting companies and their customers.