Breaking Down the OWASP Top 10 API Security Risks 2023 (& What Changed From 2019)

The OWASP Top Ten lists have been the cornerstone for application security best practices for over two decades. The 2019 list was the first edition of the OWASP API Security Top 10. The latest, OWASP API Security Top 10 2023, gives our security and engineering teams a glimpse of attack vectors that are becoming more common. With that in mind, it also helps our security teams to ensure that they have adequate coverage for security testing. The changes in the list reflect the changes in the technology landscape we see today.

Cloud-native applications have become increasingly prevalent, with many organizations utilizing other cloud technologies like serverless architectures that greatly increase the risk and footprint of our applications. This changes how you test as well as the strategy you take for ensuring our applications as well as the architecture are secure. 

The image below shows what changed at a high level. In the 2023 list, the categories in some cases are a bit broader, and some have been renamed to better describe the current landscape.

The breakdown of the changes from the 2019 to the 2023 OWASP Top 10 API Security Risks list 

From a security testing perspective, the API top 10 list has always been more in the realm of manual testing. 

Looking at the OWASP Top 10 API Security Risks 2019:

API1:2019 - Broken Object Level Authorization

This is a break in the authorization of accessing a record or object that is not intended. Such as: 

/shops/{shopName}/revenue_data.json

In this example, one shop should not be allowed to access the

revenue_data.json

file from another shop. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.

Notes on Testing:

Broken Object Level Authorization is best tested manually, as an automated scanner would not understand the difference between what should be accessible and what should not be accessible. For example: Access to any shopName in

/shops/{shopName}/revenue_data.json

 would not be treated the same as

/zipcodes/{state}/all_zipcodes.json

However, automated tools can best be used for later analysis.

API2:2019 - Broken User Authentication

This category consists of everything from poor password policies, sending clear text credentials or secrets in the URL, weak/poor JWT (JSON Web Tokens) configurations, as well as “Forgot password” or “Password reset” functionality.

Notes on Testing:

Static and Dynamic testing will perform well in this category, as both types of scanning will detect many different types of flaws. Although again there are cases that can more reliably be tested manually. One area of this category that should be tested manually (MPT) is “Forgot Password” or “Password Resets” functions. Many times, these functions are written manually rather than using a proper framework. Vulnerabilities in this area can lead to an authentication bypass.

OWASP gives great information around authentication here:

Authentication - OWASP Cheat Sheet Series

Key Management - OWASP Cheat Sheet Series

API3:2019 - Excessive Data Exposure

APIs are designed to return data. One area to be concerned with, is it returning too much data. Some generic methods can return all fields or properties in a database record. Such as:

{id}, {firstName},{lastName},{email},{dateOfBirth}

where you may only want the firstname, lastname and email. The

dateOfBirth

field would be considered sensitive, and should not be filtered client side, as it can still be accessible, or viewed if requested manually, through for example a proxy. GraphQL is designed to solve this issue, and only send the required fields.

Notes on Testing:

Automated testing is not reliable in this area, as a scanner would not have the context to know what data should be accessible and not accessible in every location. Manual testing (MPT) is recommended here.

API4:2019 - Lack of Resources & Rate Limiting

Monitoring the correct number of resources is crucial in today’s landscape. Oversizing can lead to high costs, too small can lead to poor performance or service disruptions.

There needs to be proper controls in place to limit safely the number of requests a service can handle. One way is by rate limiting, or only allowing a set number of requests per user in a set amount of time.

Another part of this is autoscaling of resources or compute nodes, mainly in cloud or containerized environments. Proper controls should be in place to prevent uncontrolled growth or over-provisioning. Define clear scaling policies and rules that align with your application's performance requirements and business goals. This is where monitoring compounds and help assist in this area.

Notes on Testing:

This should be part of the design of the API. It should also be part of the review process. For existing endpoints, an audit or review would also be sufficient to discover any gaps.

API5:2019 - Broken Function Level Authorization

This flaw category has become more relevant as applications continue to evolve into cloud native architecture and consume various cloud resources and monitoring tools. Here is an example of an endpoint that display details about a single loan by id:

https://evilbankloaner.com/customers/brightloans/loan/123

By design the following endpoint is also available to display all loans for that customer:

https://evilbankloaner.com/customers/brightloans/loan/

However, if the authenticated user was to request the following endpoint:

https://evilbankloaner.com/customers/

and authorization checks were not in place, it would serve a list of all customers that the bank is serving!

Other examples could include accessing administrative functionality, which could leak details about other user accounts etc.

Notes on Testing:

Automated scanning tools can be effective in testing account access. But these tools usually require manual review to ensure what is accessible is intended. MPT is also recommended here.

API6:2019 - Mass Assignment

Mass assignment happens when properties of a record or object, can be updated when they are not intended to be. For example, in a profile page, an API may make a PUT request, with the following JSON payload: 

{ first: "foo", last: "bar", email: "[email protected]" }

Mass assignment happens when a user sends a request that updates a property that is hidden, such as an additional property named:

isAdmin

which is a Boolean flag that determines if the user is an administrator. Sending the following payload as the user, can make himself an admin:

{ first: "foo", last: "bar", email: "[email protected]", isAdmin: 1 }

Notes on Testing:

Automated testing is not reliable in this area, as testing usually is done through a filtered word list, which consists of sending hundreds or thousands of requests to each endpoint to test if the properties exist. Manual testing (MPT) is recommended here.

API7:2019 - Security Misconfiguration

Security misconfigurations consist of server configurations specifically around security settings such as allowing deprecated security ciphers, missing security patches in the server software packages, misconfigured CORS, as well as leaked debug information in error messages as well as others.

Notes on Testing:

Static and dynamic testing shine here in this category as many of the detections can be discovered by a simple check with a very low false positive (FP) rate. From a dynamic standpoint, this category is well covered as automated scanners can run hundreds or more of checks in a short time, to ensure consistency.

API8:2019 - Injection

An API is vulnerable when client-supplied data is not validated, filtered, or sanitized by the API. This tainted input can be directly used within SQL/NoSQL/LDAP queries, OS commands, XML parsers, or Object Relational Mapping (ORM)/Object Document Mapper (ODM). An example would be input of the username in the URL.

Example payload: 

curl 'https://example.com/admin/sleep%2010'

where a

sleep

command is injected and executed where the API is directly taking user input as part of a system or OS level command.

Notes on Testing:

Injection is easily tested with automated dynamic and static scanners and can reliably be used for testing. Though a deeper analysis can be done with a manual penetration test where more architecture specific and obscure payloads can be tested when more is known about the underlying architecture.

API9:2019 - Improper Assets Management

This flaw category impacts a variety of areas that are caused more by practices than by code flaws. Documenting your assets and endpoints has always been a struggle for organizations. Data flow diagrams may change regularly, and only get updated periodically.

Notes on Testing:

This category can be tested with Application Security Posture Management (ASPM) tools such as Longbow that can help identify and document assets.

API10:2019 - Insufficient Logging & Monitoring

Many problems can arise with logs. Are we logging the correct parameters? Are the logs monitored, rotated and archived? Do we have visibility into the entire application stack? Have the logs been tampered with or is there a flaw that can allow log injection (CWE 117)?

Notes on Testing:

This area is difficult for automated dynamic scanners to detect flaws. However, static scans can usually discover most of the flaws that arise here that are code originated. Manually testing these flaws with someone who has access to see what is being injected into is going to be helpful.

Looking at the OWASP Top 10 API Security Risks 2023:

Here is the official API Security Top 10 2023 page. 

API1:2023 - Broken Object Level Authorization

This is a break in the authorization of accessing a record or object that is not intended. Such as

/shops/{shopName}/revenue_data.json

In this example, one shop should not be allowed to access the

revenue_data.json

file from another shop. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.

Notes on Testing:

This is best tested manually, as an automated scanner would not understand the difference between what should be accessible and what should not be accessible. For example: Access to any shopName in

/shops/{shopName}/revenue_data.json

would not be treated the same as

/zipcodes/{state}/all_zipcodes.json

However, automated tools can best be used for later analysis.

API2:2023 - Broken Authentication

Broken authentication can mean a lot of different things. This category holds everything from poor password policies, weak/poor JWT (JSON Web Tokens) configurations, but also back-end APIs being accessible by no authentication. This category has changed in a more broad sense as with the increase in microservices, authentication becomes more prevalent, which increases the scope to maintain.

Notes on Testing:

Static and Dynamic testing will perform well in this category, as both types of scanning will detect many different types of flaws. Although again there are cases that can more reliably be tested manually. One area of this category that should be tested manually (MPT) is “Forgot Password” or “Password Resets” functions. Many times, these functions are written manually rather than using a proper framework. Vulnerabilities in this area can lead to an authentication bypass.

OWASP gives great information around authentication here:

Authentication - OWASP Cheat Sheet Series

Key Management - OWASP Cheat Sheet Series

API3:2023 - Broken Object Property Level Authorization

See Mass Assignment above under 2019 for more details as these categories are very similar. However, the main difference in this category, is Mass Assignment is the about assigning values without control, while Broken Object Property Level Authorization is the failure to check permissions for sensitive fields during updates.

Notes on Testing:

Automated testing is not reliable in this area, as testing usually is done through a filtered word list, which consists of sending hundreds or thousands of requests to each endpoint to test if the properties exist. Manual testing (MPT) is recommended here.

API4:2023 - Unrestricted Resource Consumption

OWASP has had to modify this category to be a bit broader from the previous “Lack of Resources & Rate Limiting”. Configuration controls need to be on everything from execution timeouts, upload file size, third-party spending limits, number of records per page to return in a single request-response, etc. Also included in this now, are restrictions on email/sms/phone call limits for MFA.

There needs to be proper controls in place to limit safely the number of requests a service can handle or should handle.

Notes on Testing:

This should be part of the design of the API. It should also be part of the review process. For existing endpoints, an audit or review would also be sufficient to discover any gaps.

API5:2023 - Broken Function Level Authorization

Comments on this category have not changed from the 2019. It has also remained in this same place as previously.

Notes on Testing:

Automated scanning tools can be effective in testing account access. But these tools usually require manual review to ensure what is accessible is intended. MPT is also recommended here.

API7:2023 - Server Side Request Forgery

SSRF can allow access into internal systems, exposure of sensitive information, as well as other exploits. The adoption of microservices and ingesting third-party data has greatly increased the scope of these flaws. Here is an example of one from the OWASP page that shows the threat simply:

Example: A social network allows users to upload profile pictures. The user can choose either to upload the image file from their machine, or provide the URL of the image. Choosing the second, will trigger the following API call: 

POST /api/profile/upload_picture { "picture_url": "http://example.com/profile_pic.jpg" }

An attacker can send a malicious URL and initiate port scanning within the internal network using the API Endpoint. 

{ "picture_url": "localhost:8080" }

Notes on Testing:

SSRF can detected by Static, but also easily detected with high confidence with Dynamic scanning.

API8:2023 - Security Misconfiguration

Same suggestions as 2019 version.

Notes on Testing:

Same suggestions as 2019 version.

API9:2023 - Improper Inventory Management

This flaw has a variety of areas that are more caused by practices than by code flaws.

Inventory of an “application” has changed as the tech landscape changes. Now it is imperative that all cloud resources and services, third party services that are utilized as well as internal microservices be documented and have a clear data flow.

Notes on Testing:

This category can be tested with ASPM (Application Security Posture Management) tools such as Veracode Risk Manager, that can help identify and document assets.

API10:2023 - Unsafe Consumption of APIs

OWASP says: “Developers tend to trust data received from third-party APIs more than user input,” and more and more applications are ingesting data from third-party sources.

Supply chain attacks are becoming more and more common, and I suspect this category will rise higher in the next top 10 list.

Notes on Testing:

Static Analysis as well as Software Composition Analysis (SCA) testing will work well here. As well as manually reviewing third party data sources regularly. It is also essential to implement proper validation, and sanitization techniques for both API-received third-party data and user-provided input and ensuring that all incoming data conforms to expected formats and standards.

Conclusion 

Some flaw categories are not on the list anymore, such as injection. Newer frameworks probably played a role by offering built-in protection against these risks. But many flaw categories have remained and are included in other categories that are now expressed in a more general form. 

It's clear that securing your APIs is more crucial than ever. With the rise of cloud-based services and microservices architecture, APIs have become a critical component of modern software development. In this blog, we've delved into each of the top 10 vulnerabilities outlined by OWASP, and explored the common pitfalls and misconfigurations that can leave your APIs vulnerable to attacks. 

As we move forward in 2024, it's crucial to prioritize API security in every stage of the development lifecycle – from design to deployment. By implementing robust authentication and authorization mechanisms, documenting and auditing our API endpoints, testing and scanning regularly, and prioritizing API security, you can significantly reduce the attack surface of your APIs. Integrating Veracode’s services will help you achieve this goal, whether it is through Static Analysis, Dynamic Analysis, Software Composition Analysis (SCA), as well as Manual Penetration Testing (MPT), and our Application Security Posture Management (ASPM) solution.