Category: Governance and Compliance
OWASP API Security Top 10
Also known as: OWASP API Top 10, Top 10 API Security Risks
Simply put
The OWASP API Security Top 10 is a widely recognized list that highlights the most critical security risks affecting APIs (Application Programming Interfaces). It is maintained by the OWASP API Security Project and is designed to educate developers, security teams, and other stakeholders about common API vulnerabilities. The list is periodically updated to address evolving threats, with the most recent version released in 2023.
Formal definition
The OWASP API Security Top 10 is a risk-awareness document produced and maintained by the OWASP API Security Project that enumerates the most critical security risks specific to APIs. It serves as both a prioritized catalogue of API-specific vulnerability categories and a documentation portal for associated best practices in API development and security. The 2023 edition reflects updates to address evolving API threat landscapes. The document is intended to inform secure design, development, and testing practices for everyone involved in API development, though it is not an exhaustive taxonomy of all possible API security issues. Organizations typically use it as a baseline for threat modeling, security testing scoping, and developer education rather than as a standalone compliance checklist.
Why it matters
APIs have become the primary connective tissue of modern software architectures, powering mobile applications, microservices, third-party integrations, and cloud-native systems. As API adoption has grown, so has the attack surface they expose. The OWASP API Security Top 10 matters because it provides a focused, community-driven enumeration of the most critical security risks specific to APIs, helping organizations prioritize their defensive efforts where they are most needed. Without a clear understanding of these risks, teams may concentrate on generic web application vulnerabilities while overlooking API-specific issues such as broken object-level authorization or unrestricted resource consumption.
The list also serves as a shared vocabulary across development, security, and operations teams. By referencing a common set of well-documented risk categories, organizations can align threat modeling exercises, security testing scopes, and developer training programs around a consistent baseline. This shared understanding reduces ambiguity when triaging findings and helps ensure that security requirements are communicated clearly during API design and review.
Because the OWASP API Security Top 10 is periodically updated (with the most recent edition released in 2023), it reflects the evolving threat landscape rather than remaining static. This ongoing maintenance helps organizations stay current with emerging API attack patterns and adjust their security practices accordingly, though it should be noted that the list is not intended to be an exhaustive taxonomy of all possible API security issues.
Who it's relevant to
API Developers and Engineers
Developers building and maintaining APIs benefit directly from the OWASP API Security Top 10 as an educational resource. It highlights common vulnerability patterns that arise during API design and implementation, helping developers write more secure code and avoid well-known pitfalls such as broken authentication or excessive data exposure.
Application Security Teams
Security professionals use the list to scope penetration testing engagements, prioritize code review efforts, and define security requirements for API projects. It provides a structured framework for assessing API-specific risks and communicating findings to development teams using a shared vocabulary.
Security Architects and Threat Modelers
Architects responsible for designing secure API architectures use the Top 10 as a baseline for threat modeling. The enumerated risk categories help ensure that common API attack vectors are considered during the design phase, before code is written.
Engineering and Security Leadership
Managers and directors overseeing API development programs use the list to inform training initiatives, set security policy baselines, and measure organizational maturity against a widely recognized industry standard. It helps justify investment in API-specific security tooling and processes.
DevSecOps and Platform Teams
Teams responsible for CI/CD pipelines and API gateways can use the Top 10 to guide the selection and configuration of automated security controls, such as API-aware scanning tools and runtime protections, ensuring that common risk categories are addressed across the software delivery lifecycle.
Inside OWASP API Security Top 10
API1 - Broken Object Level Authorization (BOLA)
A vulnerability where API endpoints fail to validate that the authenticated user has permission to access a specific object, typically by manipulating object identifiers in requests. This is one of the most prevalent API security issues and is often difficult to detect through static analysis alone, as it requires understanding of authorization logic in the context of runtime data flows.
API2 - Broken Authentication
Weaknesses in API authentication mechanisms, including flawed token generation, improper credential validation, and missing or misconfigured authentication controls. This encompasses issues such as weak API key management, lack of rate limiting on authentication endpoints, and acceptance of unsigned or weakly signed JWTs.
API3 - Broken Object Property Level Authorization
A category combining excessive data exposure and mass assignment vulnerabilities. APIs may return more object properties than the client needs (over-exposure) or accept and process client-supplied properties that should not be writable (mass assignment), both stemming from insufficient property-level access controls.
API4 - Unrestricted Resource Consumption
The absence of proper limits on the size or number of resources an API client can request, leading to denial of service, elevated operational costs, or resource exhaustion. This includes missing rate limiting, lack of pagination enforcement, and unbounded query complexity.
API5 - Broken Function Level Authorization
A vulnerability where APIs fail to enforce proper authorization checks at the function or action level, allowing users to access administrative or privileged endpoints. This typically arises when authorization logic relies on client-side enforcement or inconsistent server-side checks across different API methods or endpoints.
API6 - Unrestricted Access to Sensitive Business Flows
Exposure of business-critical API flows (such as purchasing, reservation, or account creation) without adequate safeguards against automated abuse. Unlike traditional technical vulnerabilities, exploitation involves using the API as designed but at a scale or cadence that causes business harm.
API7 - Server Side Request Forgery (SSRF)
A vulnerability where an API fetches a remote resource based on a user-supplied URI without proper validation, potentially allowing attackers to reach internal services, cloud metadata endpoints, or other protected resources that are not directly accessible from outside the network.
API8 - Security Misconfiguration
A broad category covering improper or missing security hardening across the API stack, including permissive CORS policies, verbose error messages exposing internal details, unnecessary HTTP methods enabled, missing security headers, and default or overly permissive configurations in API gateways or frameworks.
API9 - Improper Inventory Management
Risks arising from lack of visibility into the full API landscape, including undocumented, deprecated, or shadow API endpoints that remain accessible. Without a maintained API inventory, organizations may fail to apply security policies consistently, leaving older or forgotten API versions exposed.
API10 - Unsafe Consumption of APIs
Vulnerabilities introduced when an API trusts data received from third-party or partner APIs without proper validation or sanitization. This includes scenarios where developers apply less stringent security controls to data from supposedly trusted external sources, creating injection or data integrity risks.
Common questions
Answers to the questions practitioners most commonly ask about OWASP API Security Top 10.
Does the OWASP API Security Top 10 cover all API security risks I need to worry about?
No. The OWASP API Security Top 10 identifies the most critical and commonly observed API security risks, but it is not an exhaustive catalog. It represents a prioritized consensus view of prevalent threats. Organizations should treat it as a starting point and supplement it with threat modeling, industry-specific risk assessments, and additional security controls relevant to their particular API architectures and business logic.
Can I achieve API security compliance simply by addressing the OWASP API Security Top 10?
Addressing the Top 10 does not equate to compliance with any regulatory or security standard. The list is a risk awareness framework, not a compliance checklist. While remediating these risks typically improves an organization's security posture, compliance frameworks such as PCI DSS, HIPAA, or SOC 2 have their own specific requirements that may go well beyond, or differ from, the categories covered in the Top 10.
How should I map the OWASP API Security Top 10 to my existing application security testing program?
Start by reviewing each Top 10 category against your current SAST, DAST, and manual testing coverage. Some categories, such as Broken Object Level Authorization (BOLA), are difficult to detect with static analysis alone and typically require runtime testing or purpose-built DAST rules with business logic context. Identify gaps where your current tooling has known blind spots, and prioritize adding targeted test cases, API-specific scanners, or manual penetration testing to cover those categories.
Which OWASP API Security Top 10 categories can static analysis tools typically detect, and which require runtime testing?
Static analysis tools may identify issues related to categories like Security Misconfiguration or Unrestricted Resource Consumption where patterns are visible in code (for example, missing rate-limiting middleware or insecure default configurations). However, categories such as Broken Object Level Authorization, Broken Function Level Authorization, and Broken Object Property Level Authorization typically require runtime or dynamic testing because they depend on how the API enforces access control decisions in the context of authenticated sessions and real data flows.
How often should I reassess my API security posture against the OWASP API Security Top 10?
Reassessment should occur at multiple intervals: whenever the OWASP project publishes an updated version of the list, when your API surface changes significantly (such as new endpoints, new authentication mechanisms, or new third-party integrations), and as part of regular security review cycles. In most cases, integrating Top 10 category checks into CI/CD pipelines for continuous assessment, alongside periodic manual reviews, provides more consistent coverage than point-in-time assessments alone.
How do I prioritize which OWASP API Security Top 10 categories to address first in my organization?
Prioritization should be driven by your specific threat landscape and API architecture rather than by the numerical ordering of the list. Conduct threat modeling to determine which categories pose the highest risk given your API exposure, data sensitivity, and user base. For example, an organization with multi-tenant APIs handling sensitive personal data may prioritize Broken Object Level Authorization above all else, while an organization exposing public data APIs might focus first on Unrestricted Resource Consumption and Security Misconfiguration.
Common misconceptions
The OWASP API Security Top 10 is the same as the OWASP Web Application Top 10, just applied to APIs.
The API Security Top 10 is a distinct project that addresses risks specific to API architectures and interaction patterns. While some categories overlap conceptually with the web application list, the API-specific list focuses on issues like broken object level authorization, improper inventory management, and unrestricted access to business flows, which reflect the unique threat landscape of API-driven systems rather than traditional web application vulnerabilities.
Automated scanning tools (SAST or DAST) can comprehensively detect all OWASP API Security Top 10 issues.
Many of the API Top 10 categories, particularly BOLA, broken function level authorization, and unrestricted access to sensitive business flows, require understanding of business logic, authorization context, and runtime behavior that automated scanners typically cannot fully assess. SAST tools may identify some misconfiguration or input validation issues at the code level, and DAST tools can detect certain authentication and configuration weaknesses, but thorough coverage of authorization and business logic flaws typically requires manual testing, threat modeling, and runtime analysis.
Addressing the OWASP API Security Top 10 is sufficient for a complete API security program.
The Top 10 is a prioritized awareness document highlighting the most critical and common API risks. It is not an exhaustive security standard or a compliance checklist. A mature API security program also requires attention to areas such as encryption in transit, logging and monitoring, incident response, secure software development lifecycle practices, and supply chain security for API dependencies, many of which fall outside the explicit scope of the Top 10.
Best practices
Implement object-level and function-level authorization checks on the server side for every API endpoint, rather than relying on client-side filtering or obscurity of endpoint paths, and validate these controls through regular manual penetration testing focused on authorization bypass scenarios.
Maintain a current, comprehensive API inventory that tracks all published, deprecated, and internal API endpoints along with their authentication requirements, data classification, and ownership, using automated API discovery tools to identify undocumented or shadow APIs.
Apply rate limiting, pagination enforcement, and resource consumption controls at the API gateway or application layer to mitigate denial of service and automated abuse of sensitive business flows, tuning thresholds based on expected legitimate usage patterns.
Integrate API-specific security testing into the CI/CD pipeline, combining SAST for detectable code-level issues (such as input validation gaps and certain misconfigurations) with DAST and manual review for authorization logic, business logic abuse, and runtime-dependent vulnerabilities.
Validate and sanitize all data received from third-party APIs with the same rigor applied to user input, applying strict schema validation and encoding practices to prevent injection and data integrity issues from upstream dependencies.
Conduct threat modeling exercises focused on API-specific attack surfaces during the design phase, explicitly mapping each API endpoint to the relevant OWASP API Security Top 10 categories to identify risks before implementation.