OWASP API Security Top 10: Risks, Examples, and How to Prevent Them

The OWASP API Security Top 10 lists the top 10 security risks that are unique to APIs and offers a helpful framework for comprehending and defending these risks. As of September 3, 2026, the current API Security Top 10 is the 2023 edition and there is no new API Security Top 10 edition from OWASP published recently. However, the general OWASP Top 10 has since been updated to 2025 edition.

APIs have become the glue that holds web applications, mobile applications, SaaS, payment systems, CRMs, databases and third party services together. Xcentric Services designs and builds mobile apps using backend and cloud infrastructure, dynamic APIs, secure databases and third-party integrations. It also goes through a QA process and testing before it is put into production, and maintains and provides security updates afterward. API security is relevant whether you are developing a new API or updating an existing system. The principle directly relates to the OWASP API Security Top 10 - API1, API3 and API5. This guide details all the API risks and practical examples along with how to avoid them.

Key Takeaways

The OWASP API Security Top 10 focuses on application programming interfaces (APIs), which are direct requests for objects, properties, functions, and business operations from clients. The current version is 2023 and its three top five categories are problems with BOLA, BOPLA and BFLA. The key messages are:

MCP security is under beta testing and is referred to as OWASP MCP Top 10.

Practical goal Identify, Test, Prevent and Remediate API Security Vulnerabilities

The API Security Top 10 is not just another rendition of the OWASP Top 10. It's about problems that occur because of how modern APIs expose data and functionality for their callers.

What is OWASP API Security Top 10?

The OWASP API Security Top 10 is a security-awareness and risk framework created and kept up by the OWASP API Security Project. It highlights vulnerabilities and design flaws that are specific to APIs and offers suggestions for developers and security teams evaluating API security.

The following is a list of ten categories:

One good way of interpreting the list is that failures of authorization are the most prevalent in the upper level of the framework. The three APIs (API1, API3 and API5) all have to do with whether a caller that has authentication is permitted access to a specific property, function, or object.

OWASP API Security Top 10 vs. the General OWASP Top 10

The OWASP API Security Top 10 and the general OWASP Top 10 are different areas of security. While the general OWASP Top 10 is 2025, the current API Security Top 10 is 2023. The general OWASP Top 10 is a general awareness document for web application security. It has categories through 2025, such as Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions.

The API focussed framework delves into the problems that APIs reveal directly. For instance, a user might only be able to view records that he or she is authorized to view in a web application. An API can also take an object identifier, like /api/orders/123. In absence of validating with the authenticated user's ownership of that order, the API may be able to reveal other customer information.

That's why knowing about BOLA vulnerability is an important part of API security. The two frameworks may overlap. Some security issues, such as security misconfiguration and SSRF, may apply to various application environments. However, the API Security Top 10 should not be considered as an older version of the general list.

The OWASP API Security Top 10: 2023 Edition

1. API1:2023 - Broken Object Level Authorization (BOLA)

When an API does not make sure the user who is currently logged in is allowed to access a particular object, it's called Broken Object Level Authorization.

Suppose you have an ecommerce API that has:

GET /api/orders/123

The application is able to check if the user is logged in correctly, but it can't check if order 123 belongs to that user. The API can then return data for a different account.

It's a classic BOLA (business object level authorization) vulnerability, since authentication has been successful, but object-level authorization has failed.

Why it occurs: Developers can assume that access to a resource is granted as part of the authentication process, or authorization may be done differently at different endpoints.

How to avoid it: Make sure to do server-side authorization checks on all requests that access a protected object. The authorization should be based on the identity of the user that has been established and the actual owner of the object or its allowed relationship with the client, and not only on the identifier that has been provided by the client.

1. API2:2023 - Broken Authentication

Broken Authentication is a problem that arises when there is a lack of API authentication, it is weak, inconsistently used, or it is configured incorrectly. For instance, an API can return authentication tokens but not require them to be timed or not validate credentials in specific API endpoints.

A single endpoint may be the only one that didn't require authentication and be exposing sensitive functionality without similar controls, appearing to be secure.

Why it occurs: Authentication is frequently spread out throughout gateways, application code, identity suppliers, and also specific services.

Preventing it: Keep authentication centralized where possible, ensure consistent use of known authentication protocols and libraries, validate tokens properly, implement proper expiration and rotations, secure credential-recovery processes, and test authentication thoroughly on the API surface.

1. API3:2023 - Broken Object Property Level Authorization (BOPLA)

BOPLA is when an API reveals or gives access to object properties that a specific user shouldn't have access to. Let's look at a profile endpoint that returns:

The data fields include name, email, role, and internal_notes.

A normal customer might require the first two, but not the internal administrative information. Similarly, an update endpoint may include a role field in a profile object, although normal users should not be allowed to update their role.

Why it happens: APIs often return the entire object instead of specifying what parts of the object a particular user can read or modify.

How to avoid it: Use explicit input schemas and output schemas; use property-level authorization; don't trust blindly and automatically bind untrusted input to sensitive model properties; test for too much data exposure and unauthorized data modification of properties.

1. API4:2023 - Unrestricted Resource Consumption

Unrestricted Resource Consumption is when an API does not provide sufficient limits on the amount of processing, bandwidth, storage, etc. that the caller can use.

A search API, for instance, could offer costly queries which aren't limited. A rogue or faulty client could make many requests, use up a lot of the database resources, or incur unexpected costs on the infrastructure.

Why it happens: Teams can be tests to make sure that a particular endpoint performs properly but not testing for repeated or resource-intensive requests and see it fail.

How to avoid it: Set proper rate limits, quotas, page limits, request-size limits, timeouts, concurrency controls, and budgets for resources. Track usage and set controls where and when needed.

For multi-tenant SaaS platforms, this is particularly significant because too many people using too much of the platform can impact the other users. If this intersects tenant isolation and noisy neighbor issues, check out our multi-tenant SaaS architecture guide.

1. API5:2023 - Broken Function Level Authorization (BFLA)

When an API function is accessible by a user it is considered Broken Function Level Authorization. Assume that there is an app with recurring admin and customer tasks. Access to updating the profile should be granted to a customer, and only the administrators should have access to deactivate an account.

If the backend has an administrative function but the function is not properly secured by the authorization policy, the lower level account may be able to access the administrative function. Here lies the essence of the broken level authorization function problem.

Why it happens: Authorization rules can be configured on the UI, but not at the API.

How to mitigate it: Establish authorization at server for all protected functions. Establish roles and permissions in one place; deny everything and test privileged identities and unprivileged identities on the same API operations.

1. API6:2023 - Unrestricted Access to Sensitive Business Flows

Sensitive Business Flows in which the valuable business processes can be automated or misused without proper controls.

A valid API endpoint that lets the audience book seats online could be a consideration. The endpoint could be fully authenticated and authorized but if all authentication and authorization were removed, one actor could reserve seats over and over again and wreak havoc on the other actors. The issue is not always an authorization failure, however.

Why it occurs: It is possible that security controls focus on individual requests instead of the entire business process.

How to avoid it: Identify workflow that are sensitive to abuse, set appropriate rate controls, detect abnormal usage, and think about having controls specific to the business for high-value operations like purchases, registrations, reservations, promotions, or verification processes.

1. API7:2023 - Server Side Request Forgery (SSRF)

Server Side Request Forgery (SSRF) occurs when an API accesses another location on the server that can be manipulated by an attacker's input.

An API that fetches an image or imports data from a provided URL, for instance, might enable the server to reach a destination that the server's designers didn't originally have access to.

Why it happens: Developers could assume the URLs provided by users are safe, and that they can use anywhere the backend is deployed.

How to prevent it: Restrict and validate outbound destinations, use allowlists as needed, separate network zones, limit access to internal services and do not trust the URLs provided by the client without validation.

Appliance and network level security measures need to be taken for SSRF prevention.

1. API8:2023 - Security Misconfiguration

Security Misconfiguration is the presence of inappropriate security controls, weak defaults, unnecessary functionality, or insecure settings in an API and/or its supporting infrastructure. They range from verbose error responses that expose implementation details, to overly liberal cross-origin policies, through to documentation being exposed without the runtime keywords and settings being removed from production.

Why it happens: There are many layers that are essential to modern APIs, such as cloud infrastructure, gateways, frameworks, containers, databases, and third-party services.

How to avoid it: Set up configuration baselines with secure configuration, remove extra functionality, disable debugging in production, limit information disclosure, be aware of CORS and carefully review changes to the configuration.

Configuration management is not a single deployment project, but a part of the API security lifecycle.

1. API9:2023 - Improper Inventory Management

Improper Inventory Management is when an organization has poor visibility into its APIs, versions, endpoints, environments, dependencies, etc. It is possible that a business knows about its existing /api/v2/ service but may have an older one that is still publicly exposed and not well monitored /api/v1/. The forgotten endpoint can be a liability to security.

Why it happens: Applications change rapidly. The API landscape can be greater than expected in development, testing, staging, partner, mobile and legacy environments.

How to avoid it: Keeping a proper API inventory, documenting the API's and versions, assign owners, monitor exposed services, retire outdated versions, and test security across the entire API estate.

1. API10:2023 - Unsafe Consumption of APIs

Unsafe Consumption of APIs is when an Application does not validate, secure or resiliency check the data received from an external API sufficiently. For instance, an application can use a third-party API and make various assumptions about its responses, such as its response structure, its security requirements, etc.

If the external service changes its behavior, it can be compromised, or return unexpected data, the consuming application can process it in an unsafe manner.

Why it occurs: Developers tend to be more specific in validating data directly received from the user than data received from third parties.

Prevention: Validate external responses, set timeouts, secure transport, proper authentication, monitoring third-party dependencies, handling unexpected data responsibly, and don't unwittingly pass input provided by an outside source into a sensitive operation.

What Changed Between the 2019 and 2023 OWASP API Security Top 10?

This 2023 Update not only renamed the items, but also updated and reframed a few categories. OWASP also noted that authorisation was still a big issue as there were three of the first five categories about authorisation.

Security can be integrated into the development process, not simply added on as a last minute checklist. For instance, when designing the Xcentric Services architecture, issues like authentication, authorization, API security, input validation, database handling, integrations, and application performance can be tackled. It's also had published development work that focuses on such security characteristics as JWT authentication, OAuth 2.0, input validation, rate limiting, HTTPS and dependency security.

API Security in the Current OWASP Framework Landscape

Once you have read about OWASP API Security Top 10, you've only just begun for businesses that are developing an API, SaaS platform, mobile application, ecommerce system or enterprise web application. The harder question is how to apply those ideas to the creation of secure application design and production code.

That's the difference that makes a difference for a business that hires a new API. A secure API is not added to the system at the end of the development process. Security should impact endpoint design, identity and permission modelling, data exposure, integration with third-party services, and impact on application behaviour when it is used in abnormal scenarios.

The security program for the APIs employs static analysis.This security program uses static analysis for the APIs. Where an existing API has been deployed, Xcentric Services can also work security from a remediation standpoint.

The API inventory, authentication, object-level authorization, function-level authorization, sensitive data exposure, rate limiting, business workflows, server-side requests, configuration, third party integrations and legacy endpoints can all be evaluated as part of a practical assessment.

This can then be followed by identify, prioritize, remediate, retest.

This is especially helpful for companies that have a legacy application, grew their API over the course of many years, or are ready to take an existing SaaS offering to bigger companies.

Xcentric Services is a web and application development company specializing in API development, backend architecture, database integration, cloud-based infrastructure, and security engineering. It features development across RESTful and GraphQL APIs, scalable architecture, third party integration, and back-end systems.

Secure Development of API Services for SaaS and Mobile Applications with Xcentric Services

The OWASP API Security Top 10 list is best utilized when it's integrated into the development and security process and not just a document that is read once and forgotten.

The first step is to determine your API endpoints and data flows. Next, explore authentication, object-level authorization, property-level access, privileged functions, resource consumption, sensitive business processes, server-side requests, configuration, API inventory, and third-party integrations.

Once you have made a decision to build an application that is safe, the next step is a structured security assessment of the existing application to determine which risks exist and which need to be remediated. In the case of a new product, it is more effective to add these controls into the product architecture before vulnerabilities are in the code base.

Xcentric Services can assist businesses in designing, developing, evaluating and enhancing API-driven applications while taking into account security factors along with scalability, performance, integrations and user experience. From the creation of a SaaS platform to a mobile app, ecommerce system, enterprise portal, or custom web application, the team can guide you through the security requirements and help you make informed development choices.

If your business requires the technical know-how to develop or enhance that API architecture, Xcentric Services can help you make the OWASP API Security Top 10 a viable security and development approach.