OWASP API Security Top 10
the 2023 reference for API risk
The OWASP API Security Top 10 is the open list of the most critical risks specific to APIs, maintained by the Open Worldwide Application Security Project. The 2023 edition replaces the 2019 list and shifts the centre of gravity towards authorisation, business logic abuse, and API consumption risk. SecPortal runs API security testing engagements as structured records, with findings mapped to API1 through API10 alongside CVSS 3.1 vectors and CWE identifiers.
No credit card required. Free plan available forever.
OWASP API Security Top 10: a risk list aimed at the API surface, not the web one
The OWASP API Security Top 10 is a separately maintained list of the most critical risks specific to APIs, published by the Open Worldwide Application Security Project. The 2023 edition replaces the 2019 list and shifts the centre of gravity towards authorisation, business-logic abuse, and the risk of consuming upstream APIs without treating them as untrusted sources. The list is freely available under a Creative Commons licence and is the risk language most regulated procurement frameworks, pentest reports, and bug bounty programmes now use when the engagement covers an API surface.
The headline change in 2023 is the recognition that APIs are different from web applications at the threat model layer, not just at the protocol layer. Authentication is token-based rather than session-based, clients are often other services rather than browsers, and resource consumption and business-flow abuse become first-class risk categories rather than sub-bullets. The 2023 list reflects that shift. The OWASP Top 10 framework reference covers the web-application risk list; this page covers the parallel risk list aimed at the API surface specifically.
What changed between 2019 and 2023
The 2023 edition keeps BOLA at number one, retires excessive data exposure and mass assignment as separate categories (folded into BOPLA at API3), promotes SSRF to a named risk at API7, broadens API4 from rate limiting to resource consumption, and introduces two new risks (API6 business-flow abuse and API10 unsafe consumption of APIs). The shape of the list now reflects API engagements as practitioners actually run them.
2019 to 2023: BOLA still leads
API1:2023 Broken Object Level Authorization keeps the top slot it held in 2019. The reason is structural. Authorisation at the object level breaks at the application layer and is invisible to schema validation, transport security, and rate limiting. The mitigation is the same in 2023 as it was in 2019: enforce object-level authorisation in the controller or service layer against the authenticated principal, not against the request signature or the path prefix.
New in 2023: BOPLA, business flows, and unsafe consumption
Three risks were introduced or substantially reframed for 2023. API3 BOPLA unifies the 2019 excessive data exposure and mass assignment risks into one property-level authorisation category. API6 covers unrestricted access to sensitive business flows: technically valid traffic that is abusable at the business layer (scalping, fake account creation, credential stuffing across accounts). API10 covers unsafe consumption of APIs, the risk of trusting upstream services without applying client-grade validation to their responses.
Reframed: SSRF graduates and resource consumption broadens
API7 SSRF moved from a sub-bullet of API security misconfiguration in 2019 to a named risk in 2023 because cloud metadata services (169.254.169.254 on AWS, GCP, Azure) and webhook-driven APIs made SSRF a routine API attack surface. API4 broadened from rate limiting to unrestricted resource consumption to capture CPU, memory, payload size, query depth, and downstream API quotas as economic-impact dimensions, not just request-rate dimensions.
Stable: misconfiguration and inventory remain
API8 security misconfiguration and API9 improper inventory management carry forward from 2019 with sharper framing. The recurring failure pattern in 2023 reports is undocumented v0 and shadow API endpoints serving production traffic with weaker controls than v1. The remedy is treating API inventory as an operational asset with a documented spec per environment and an enforced sunset path.
The ten risks: what to test, how to remediate
Each entry below names the API risk identifier, summarises the failure pattern, and notes a working test approach. The exhaustive guidance is in the OWASP source document; the framing here is what consultancies, internal AppSec teams, and pentest firms tend to encounter first when an engagement scopes against the API Top 10 rather than against the web list.
API1:2023 Broken Object Level Authorization (BOLA)
Endpoints that expose object identifiers and fail to verify the authenticated principal is authorised to access the specific object. The most common API risk in production engagements.
Test approach. Enumerate object IDs across roles, tenants, and account boundaries. Compare responses for the same object ID under different principals. Look for authorisation that depends on the path prefix or a header rather than the authenticated principal.
API2:2023 Broken Authentication
Authentication weaknesses at the API layer: missing authentication on sensitive endpoints, predictable or replayable tokens, weak credential recovery, missing brute force protection, and trust in unverified JWT claims.
Test approach. Walk authentication-bearing endpoints with empty, expired, and forged tokens. Inspect JWT validation against the issuer signature and claims. Attempt credential stuffing against rate-limited endpoints to confirm the limiter binds to the authenticated principal rather than to the IP.
API3:2023 Broken Object Property Level Authorization (BOPLA)
Property-level authorisation failures: reading properties the principal should not see (admin-only fields in a /users response) and writing properties the principal should not set (a role field in a profile update body).
Test approach. Inspect full response bodies for fields a non-admin principal should not see. Send unexpected property names in writes (role, isAdmin, tenantId) and observe whether the API silently accepts them. Compare write paths against documented schemas to surface mass-assignment risk.
API4:2023 Unrestricted Resource Consumption
API endpoints that fail to bound the resources a single request or principal can consume: CPU, memory, payload size, query depth, downstream API quotas, and service-provider billing.
Test approach. Submit large payloads, deeply nested objects, expensive query parameters, and pagination that returns more rows than documented. Watch for downstream calls without timeouts and for batch operations that fan out without per-principal limits.
API5:2023 Broken Function Level Authorization (BFLA)
Function-level authorisation failures, the analogue of BOLA at the action level. Admin or tenant-scoped endpoints reachable from non-admin or cross-tenant tokens.
Test approach. Walk admin and tenant-scoped endpoints with non-admin and cross-tenant tokens. Look for authorisation that lives in the UI rather than the API, and for path prefix or header-based gating that an attacker can replicate.
API6:2023 Unrestricted Access to Sensitive Business Flows
New in 2023. Business flows that work as designed at the technical layer but are abusable at the business layer because the API does not bound the rate at which the flow can be executed (scalping, fake account creation, credential stuffing across distributed accounts).
Test approach. Map business flows with economic value and model how they would be abused. Test per-principal velocity limits, anti-automation signals (CAPTCHA, device fingerprinting, behavioural triggers), and whether business-flow rate limits exist alongside the technical rate limiter.
API7:2023 Server-Side Request Forgery (SSRF)
APIs that take a URL or hostname from a client and cause the server to fetch it. Cloud metadata services and webhook-driven APIs make SSRF a routine API attack surface in 2023.
Test approach. Submit internal hostnames, link-local addresses (169.254.169.254), file:// and gopher:// schemes, and DNS rebinding payloads. Verify outbound traffic policies and whether the API uses IMDSv2 on AWS workloads.
API8:2023 Security Misconfiguration
Default credentials on management interfaces, missing or wrong CORS configuration, missing HTTP security headers on API responses, verbose error pages that leak stack traces, and unpatched software in the API stack.
Test approach. Run the same configuration review used for web apps applied at the API boundary. Validate CORS against documented origins. Inspect error responses under invalid input. Fingerprint the API stack against known CVEs.
API9:2023 Improper Inventory Management
APIs that exist in production without an authoritative inventory, without a documented lifecycle, and without a plan for retirement. The classic failure pattern is the undocumented v0 endpoint still serving traffic years after v1 went live.
Test approach. Enumerate subdomains, walk historic Swagger and Postman exports, and compare the deployed surface to the documented inventory. Surface unversioned, deprecated, and shadow endpoints that ship without the controls applied to current versions.
API10:2023 Unsafe Consumption of APIs
New in 2023. The risk of trusting upstream APIs without applying client-grade input validation, transport security, and error handling to responses from those APIs.
Test approach. Review how the API treats responses from upstream services, especially when responses contain links, identifiers, or credentials. Test pass-through redirects from third parties, propagation of upstream authentication failures, and trust placed in unsanitised upstream data.
For the matching vulnerability-class detail pages, see broken object level authorisation, broken function level authorisation, broken object property level authorisation, broken authentication, mass assignment, broken access control, server-side request forgery, JWT vulnerabilities, OAuth misconfiguration, missing rate limiting, and GraphQL vulnerabilities. Each page covers detection, CVSS context, and remediation guidance that the API Top 10 risk identifiers cite at a higher level.
Reporting expectations: a finding worth retesting against
An API security report written against the OWASP API Security Top 10 is comparable across providers when the finding records carry a small, consistent set of fields. Skipping any of them turns the report into a finding list that the buyer cannot benchmark and the auditor cannot cite.
- API risk identifier on every finding (API1:2023 through API10:2023) so the engagement reads as a test against the framework rather than against a generic vulnerability list
- CWE identifier alongside the API risk identifier (BOLA maps to CWE-639, BFLA to CWE-285, BOPLA to CWE-915 and CWE-213, SSRF to CWE-918) so the finding is portable to other taxonomies
- CVSS 3.1 vector per finding so severity is machine-readable and comparable across engagements; SSVC or another stakeholder-specific taxonomy where the buyer asks for it
- Authentication context recorded on every finding: the role, tenant, and credential type the test was performed under, so reproducibility survives the testing window
- Endpoint and method recorded canonically (POST /api/v2/users/{id}/role) so the report cannot be misread as a test against a different version or path
- Evidence inline: the request, the response, the screenshot, and the curl reproduction stay attached to the finding rather than living in a separate working folder
- Out-of-scope endpoints declared explicitly so the report cannot be read as a stronger claim than was tested (the endpoint list, the testing window, and the authentication context all belong here)
- Retest scope agreed at kickoff (which findings are eligible for retest, the retest window, and the verification method per finding) so the report can carry verified-fixed status into closure
For the wider engagement scaffolding around an API security test, see the API security testing use case and the matching API security testing checklist. For the depth and pricing decisions, see the pentest scope calculator and the pentest pricing models research, which together cover how API engagements get scoped without leaving the buyer to reconstruct the depth claim later.
How the API Top 10 sits next to OWASP Top 10, ASVS, WSTG, and CWE
The OWASP API Security Top 10 is rarely cited in isolation. It is the API-specific risk language that complements other OWASP documents and the underlying CWE taxonomy. The contrast below is a working view, not a buyer comparison: the practitioner question is which references to pair the API Top 10 with, not which to pick instead of it.
OWASP API Security Top 10 vs OWASP Top 10 (web)
The OWASP Top 10 is a ranked list of risks for web applications: a browser, a session, a server, an HTTP request and response. The OWASP API Security Top 10 is a separate list specific to APIs, where the client is often another service, the authentication boundary is a token rather than a session cookie, and the protocol surface is JSON, GraphQL, or gRPC over HTTP. The two lists overlap (broken access control, security misconfiguration) but the API list adds API-specific risks (BOLA, BFLA, BOPLA, business-flow abuse, unsafe consumption) that the web list does not separate cleanly. Engagements that include both a web and an API surface should reference both lists rather than substituting one for the other.
OWASP API Security Top 10 vs OWASP ASVS
OWASP ASVS is a verification standard with 14 chapters and explicit Level 1, Level 2, and Level 3 requirements; ASVS V13 covers API and web service requirements specifically. OWASP API Security Top 10 is a risk list, not a verification standard. The two compose: an ASVS L2 engagement against an API surface uses ASVS V13 as the requirement set and the API Top 10 as the risk taxonomy that maps findings to industry-recognised categories. Mature programmes write reports against both: ASVS for the requirement claim, API Top 10 for the risk language buyers and auditors use.
OWASP API Security Top 10 vs OWASP WSTG
The OWASP Web Security Testing Guide (WSTG) is a how-to reference for testing techniques. The API Top 10 is what the application is being tested against. WSTG describes how to test for SSRF; the API Top 10 says SSRF is an API7:2023 risk and what the impact looks like at the API layer specifically. Many engagements pair both: WSTG techniques applied to API endpoints, with findings reported under API1 through API10.
OWASP API Security Top 10 vs CWE
CWE (Common Weakness Enumeration) is the underlying taxonomy of software weaknesses. The API Top 10 is a curated risk list aimed at API engagements. Mature reports cite both: API1:2023 BOLA on the engagement-language side, CWE-639 (Authorisation Bypass Through User-Controlled Key) on the taxonomy side. Buyers comparing reports across providers should expect both citations on every finding, because the API Top 10 evolves on a multi-year cadence while CWE is the durable reference.
Buyers procuring an ASVS-backed verification of an API surface should pair the API Top 10 with OWASP ASVS (chapter V13 in particular) as the requirement set, and with PTES as the engagement-level methodology. Buyers needing the headline web list alongside the API one should reference OWASP Top 10 for the web tier and the API Top 10 for the API tier separately, rather than substituting one for the other on a mixed scope.
OWASP API Security Top 10 for AppSec teams, pentest firms, and DevSecOps programmes
The list is read differently depending on which side of the engagement you sit on. AppSec teams use the API Top 10 as the internal risk language engineering builds against, and as the structure that triages findings from authenticated DAST, SAST, and SCA into one comparable picture. Pentest firms use the API Top 10 as the language their report is written against, and as the vocabulary that lets clients compare engagements over time. DevSecOps programmes use the API Top 10 as the structure their CI checks are calibrated against, especially API4 unrestricted resource consumption and API9 improper inventory management.
The persona-specific entry points are SecPortal for application security teams, SecPortal for cybersecurity firms, and SecPortal for DevSecOps teams. Each anchors a different view of the same API engagement record.
Where SecPortal fits in an OWASP API Security Top 10 engagement
SecPortal is the operating layer for an API security engagement scoped against the OWASP API Security Top 10. The platform handles scope, authentication context, requirement coverage, authenticated DAST evidence, finding triage, retests, and the final deliverable so the engagement runs as a single workflow rather than a long email thread with attachments. For consultancies running API security engagements on behalf of multiple clients, the security consultants workspace bundles that with branded client portals.
- Authenticated scanning runs DAST modules behind the login screen against API endpoints, with credentials stored encrypted at rest under AES-256-GCM (cookie, bearer token, basic, or form login), so API1 BOLA, API2 broken authentication, API5 BFLA, and API3 BOPLA findings have reproducible evidence across retest cycles
- Findings management stores every finding with a CVSS 3.1 vector, severity, CWE identifier, OWASP API category, evidence, and a mapping field for the API risk identifier (API1:2023 through API10:2023), so the report writes itself from the underlying record rather than from a blank template
- Engagement management captures the API surface, the authentication model, the in-scope endpoints, the rules of engagement, the testing window, and the retest scope as a structured record so the engagement scaffold is the workflow rather than a contract attachment
- AI-assisted reports compose the executive summary, the technical body, and the remediation roadmap from the live engagement and findings, citing the API risks exercised rather than starting from a blank page
- Client portal delivers the verification on the consultancy subdomain so buyers see the live engagement, retests, and closure status rather than a frozen PDF, with branded styling that matches enterprise reporting expectations
- Compliance tracking lets one OWASP API Security Top 10 engagement satisfy framework mappings to PCI DSS Requirement 6, ISO 27001 Annex A.8.8, and SOC 2 Trust Services Criteria without rebuilding the bundle for each audit
- Continuous monitoring schedules authenticated scans against the API surface so API4 unrestricted resource consumption, API8 security misconfiguration, and API9 improper inventory management are detected against drift between assessment windows rather than only at the next engagement
Looking for the engagement workflow itself, end to end? The penetration testing use case and the pentest project management use case capture how SecPortal turns an API-scoped engagement into a structured record covering scope, findings, retests, and the deliverable. For the retest mechanics specifically, see the pentest retesting use case. For the scanner-output triage that pairs with manual API testing, see the scanner result triage use case.
For the procurement and pricing context (how buyers should compare API security proposals on effective day rate, requirement coverage, retest policy, and reporting depth), see the pentest pricing models research and the pentest scope creep research, which together cover the contract structure that holds an API security verification claim together over time.
Key control areas
SecPortal helps you track and manage compliance across these domains.
API1:2023 Broken Object Level Authorization (BOLA)
BOLA covers any API endpoint that exposes object identifiers (numeric IDs, UUIDs, slugs) and fails to verify that the authenticated principal is authorised to access the specific object. The 2023 edition keeps BOLA at number one because object-level authorisation breaks at the application layer and is invisible to schema validation, signature checking, and rate limiting. Test by enumerating object IDs across roles, tenants, and account boundaries; remediate at the controller or service layer with authorisation checks tied to the authenticated principal rather than to the request signature.
API2:2023 Broken Authentication
API2 covers weaknesses in the authentication layer itself: missing authentication on sensitive endpoints, predictable or replayable tokens, weak credential recovery, missing brute force protection, and trust placed in unverified JWT claims. Test by walking the authentication endpoints with an empty or forged token, by attempting credential stuffing against rate-limited endpoints, and by inspecting how the API treats expired, revoked, or invalid tokens. Remediate by enforcing authentication on every protected route, validating JWT signatures and claims against a known issuer, and applying rate limiting and lockout to credential-sensitive endpoints.
API3:2023 Broken Object Property Level Authorization (BOPLA)
BOPLA replaces excessive data exposure and mass assignment from the 2019 list and unifies them into one property-level authorisation risk. The two failure modes are reading properties the principal should not see (a /users endpoint that returns admin-only fields in the response) and writing properties the principal should not set (a profile update endpoint that accepts a role field in the request body). Test by inspecting full response bodies against role expectations and by sending unexpected property names in writes; remediate with explicit allow lists at the API boundary rather than relying on the ORM or the schema to filter client-controlled input.
API4:2023 Unrestricted Resource Consumption
API4 covers API endpoints that fail to bound the resources a single request or principal can consume: CPU, memory, disk, bandwidth, downstream API quotas, and service-provider billing. The 2023 edition pulled this risk forward because cloud-native APIs make resource-exhaustion attacks both cheaper to launch and more expensive to absorb. Test by submitting large payloads, deeply nested objects, expensive query parameters, and pagination that returns more rows than the documentation implies. Remediate with request size limits, query depth and complexity limits, rate limiting tied to the authenticated principal, and timeouts on downstream calls.
API5:2023 Broken Function Level Authorization (BFLA)
BFLA is the function-level analogue of BOLA: an API exposes administrative or privileged functions and fails to verify the authenticated principal is authorised to call them. The classic failure pattern is admin endpoints reachable from a non-admin token because the authorisation check is in the UI rather than the API. Test by walking the admin and tenant-scoped endpoints with non-admin and cross-tenant tokens; remediate with function-level authorisation checks that depend on the authenticated principal rather than on a header, a hidden field, or a path prefix.
API6:2023 Unrestricted Access to Sensitive Business Flows
API6 is new in 2023 and covers business flows that work as designed at the technical layer but are abusable at the business layer because the API does not bound the rate at which the flow can be executed. The OWASP examples include scalping (buying inventory faster than humans can), credential stuffing across distributed accounts, and bulk-creation of fake accounts. Test by mapping business flows that have economic value and modelling how they would be abused; remediate with anti-automation controls (CAPTCHA, behavioural signals, device fingerprinting), per-principal velocity limits, and business-flow-specific rate limiting that complements the technical rate limiter.
API7:2023 Server-Side Request Forgery (SSRF)
API7 covers any API that takes a URL or hostname from a client and causes the server to fetch it. SSRF gets dedicated billing in 2023 because cloud APIs that proxy webhooks, fetch metadata, or render previews are now widespread, and the cloud metadata service (169.254.169.254 on AWS, GCP, Azure) is a high-value target. Test by submitting internal hostnames, link-local addresses, file:// schemes, and DNS rebinding payloads; remediate with allow-list-based URL validation, denying private and link-local ranges, requiring outbound traffic through an explicit proxy, and using IMDSv2 on AWS workloads.
API8:2023 Security Misconfiguration
API8 carries forward the 2019 misconfiguration risk and covers default credentials on management interfaces, missing or wrong CORS configuration, missing HTTP security headers on API responses, verbose error pages that leak stack traces, unpatched software in the API stack, and unnecessarily permissive default policies. Test with the same fingerprinting and configuration review used for web applications, applied at the API boundary; remediate with infrastructure-as-code review, baseline configuration policies enforced at deployment time, and CI checks that fail builds on regressions in CORS, headers, and error verbosity.
API9:2023 Improper Inventory Management
API9 is a renamed successor to the 2019 improper assets management risk and covers APIs that exist in production without an authoritative inventory, without a documented lifecycle, and without a plan for retirement. The classic failure pattern is the unversioned, undocumented v0 endpoint still serving traffic years after v1 went live. Test by enumerating subdomains, walking historic Swagger and Postman exports, and comparing the deployed surface to the documented inventory. Remediate by treating API inventory as an operational asset: a documented spec per environment, a documented deprecation policy, and a documented sunset path enforced in the platform rather than on a wiki page.
API10:2023 Unsafe Consumption of APIs
API10 is new in 2023 and covers the risk of trusting upstream APIs without applying the same input validation, transport security, and error handling expected on traffic from untrusted clients. The 2023 examples include APIs that pass through redirects from third parties without re-validation, accept unsanitised data from upstream APIs in privileged contexts, and propagate authentication failures from upstream calls in a way that reveals downstream topology. Test by reviewing how the API treats responses from upstream services, especially when those responses contain links, identifiers, or credentials. Remediate by treating upstream APIs as untrusted: apply schema validation, transport security, and timeouts as if the upstream were a client.
Run OWASP API Security Top 10 testing as a tracked engagement
Map findings to API1 through API10, run authenticated DAST against the API, and deliver a verification record clients and auditors can read. Start free.
No credit card required. Free plan available forever.