OWASP API SECURITY TOP 10 EXPLAINED

The OWASP API Security Top 10 is a periodically refreshed list of the ten most critical security risks affecting application programming interfaces (APIs), published by the OWASP Foundation. The current edition is the 2023 release, comprising ten categories from API1:2023 (Broken Object Level Authorization) to API10:2023 (Unsafe Consumption of APIs). It complements the broader OWASP Top 10 by addressing the distinctive threat profile that APIs present — programmatic clients, automated abuse patterns, layered authorisation — which the general Top 10 does not cover well.

Because APIs have a structurally different threat profile than browser-mediated web applications. Browsers enforce certain controls (same-origin policy, cookie scoping, CORS) that APIs do not benefit from; APIs are consumed by programs that can iterate at machine speed; APIs often expose more than their designers intended (shadow APIs, deprecated endpoints, undocumented behaviour); and API authorisation is multi-layered (object level, function level, property level) in ways the general Top 10’s single ‘Broken Access Control’ framing does not capture. The API Security Top 10 was created precisely because applying the general Top 10 to APIs systematically missed the most prevalent API failure patterns.

BOLA stands for Broken Object Level Authorization. It describes the failure where an API serves an object to a caller who should not be authorised to access that specific object — typically because the API checks authentication (is the caller logged in?) but does not check object ownership (does this caller own this specific resource?). Iterating through object IDs (/orders/123, /orders/124, /orders/125…) reveals data belonging to other users. BOLA is ranked API1 because the OWASP project team’s telemetry analysis consistently shows it as the most prevalent and most exploitable API risk — a pattern where authorisation is only partially correct and the gap is trivial for adversaries to exploit at API speed.

It is the principal technical normative document for Module C (API / Microservices Security) — the basis of evaluation, not just a prioritisation lens. This is structurally different from the general OWASP Top 10, which Guardian uses as a prioritisation lens applied across the ASVS-anchored evaluation in Modules A and B. For Module C, Guardian’s evaluation verifies the certified product against API1:2023 through API10:2023, with depth scaling per the chosen Level (1 Basic / 2 Advanced / 3 High-Risk Critical). Show-All FAQs (in ‘See all FAQs’ expansion)

Several material changes. API3 was renamed and refocused — from ‘Excessive Data Exposure’ (a specific failure mode) to ‘Broken Object Property Level Authorization’ (the underlying root cause). API4 was renamed and broadened — from ‘Lack of Resources & Rate Limiting’ to ‘Unrestricted Resource Consumption’ to include cost amplification and third-party API cost abuse. API6 was added new — ‘Unrestricted Access to Sensitive Business Flows’ — addressing business-flow abuse where each request is authorised but aggregate behaviour constitutes abuse. API10 was added new — ‘Unsafe Consumption of APIs’ — addressing the supply-chain dimension of consuming upstream APIs. API7 (SSRF) was elevated to its own category. The 2023 edition is the current operative reference for new Module C engagements.

Yes. As with all OWASP publications, the API Security Top 10 is published as a public good, freely available with no licensing fees. Anyone — engineers, organisations, regulators, certification bodies — can use it without payment. The canonical reference is at owasp.org/API-Security/. What you pay for, when obtaining Guardian SecureApp™ Module C certification, is accredited third-party evaluation against the API Top 10 — not access to the standard itself.

BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object Reference) describe overlapping but not identical issues. IDOR is the older, more general framing — the use of direct references to objects (such as numeric IDs) without proper access checks. BOLA is the more precise API-context framing — failures of object-level authorisation specifically, often at API endpoints. All BOLA findings can be described as IDOR, but the API-specific framing emphasises that this is the most prevalent API failure pattern, requiring authorisation checks at every endpoint that returns or accepts object references.

Yes. The API Top 10 is API-protocol-agnostic — it applies to REST, GraphQL, gRPC, SOAP, WebSocket, and any other interface where machine-to-machine communication occurs. The categories are framed in terms of underlying authorisation, authentication and resource-handling concerns rather than REST-specific patterns. GraphQL has some specific patterns (introspection endpoint exposure, query complexity attacks, batched-query abuse) that map naturally to existing categories — query complexity is a clear API4 (Unrestricted Resource Consumption) concern, for example. Module C engagements scope GraphQL surfaces explicitly during scoping.

API6 addresses business-flow abuse where each individual request is authorised but the aggregate behaviour constitutes abuse — automated account creation, automated booking, automated comment posting, automated rewards-redemption, automated price scraping. Defending against API6 requires behavioural anti-automation (rate analysis, pattern detection, CAPTCHA challenges, device fingerprinting) rather than just per-request authorisation. The category is newly added in the 2023 edition and reflects the rise of bot-driven fraud against modern APIs.

The API Top 10 is the principal normative — the basis of evaluation. ASVS V13 (API and Web Service Interfaces) is consulted as a complementary reference where applicable, particularly for APIs that the certified product consumes (rather than only exposes). Where the certified product combines API surfaces with web UIs or SaaS multi-tenant platforms, combined-module engagements (Module A + C, Module B + C) apply the appropriate normative to each surface. The Module C page at /certification/api-security details how the standards combine in practice.

Module C engagement durations depend on the chosen Level and the API surface size. Indicative ranges: Level 1 (Basic) 4–7 weeks; Level 2 (Advanced) 7–11 weeks; Level 3 (High-Risk / Critical) 11–16 weeks. Combined-module engagements (Module A + C or Module B + C) run longer. Largest variables are applicant responsiveness during findings closure and the complexity of the API estate (number of endpoints, number of versions, presence of partner integrations). Detailed timeline guidance is at /certification/api-security.

Yes. Module C is designed for microservice estates where multiple internal and external API surfaces operate together. Scoping defines whether all microservices, only externally-exposed APIs, or a defined subset are in scope. The Public Scope Statement names the boundary precisely. For very large microservice estates, scoping conversations may identify a representative subset by mutual agreement, with the boundary explicitly stated in the Scope Statement. Pricing reflects scope size.

API-specific regulations — open banking frameworks (UK Open Banking, EU PSD2 / PSD3, India’s Account Aggregator framework), payment platform regulations, healthcare API standards — increasingly reference OWASP-aligned API security expectations either explicitly or by analogy. Specific regulatory acceptability of API Top 10-based certification varies by regulator and is discussed at scoping. Where a regulator names specific API security controls beyond the Top 10, those are addressed in addition to the Top 10 evaluation. The API Top 10 produces interpretable, accredited evidence that regulators find more substantive than self-declarations.

API9 addresses the API estate’s inventory hygiene — old API versions still serving traffic that should have been retired, deprecated endpoints not removed, internal-only endpoints inadvertently exposed in production, shadow APIs not in any documented inventory, undocumented endpoints surviving feature retirements. Evaluation activities at Module C include review of the documented API inventory, comparison against active surface (active discovery at higher Levels), version-history analysis, and verification that retired endpoints are genuinely retired. Adversaries find what defenders did not know was there — API9 is engineered to surface those gaps.

OWASP has not committed to a fixed cadence for either the general Top 10 or the API Top 10. Historical pattern suggests every 3–4 years is typical. The 2019 → 2023 cycle reflects this. Whether OWASP accelerates refresh cadence in response to the rapid evolution of API security threats — particularly with the rise of AI / LLM API surfaces and agent-driven API consumption — remains to be seen. Guardian’s adoption discipline tracks OWASP’s publication cycle: when a new edition is published, our Technical Review Panel reviews and adopts it into GSA-PR-01 with appropriate transition guidance.

Three structural ways, paralleling ASVS and the general Top 10. First, accredited issuance: Guardian operates under ISO/IEC 17065 with annual UAF surveillance — the procedural integrity is itself audited, which self-assessment cannot replicate. Second, public verifiability: every Module C certificate is publicly listed in our directory at /directory, searchable by certificate number — a self-assessment is a private document. Third, ongoing surveillance: Module C certificates are subject to annual or semi-annual surveillance (depending on Level), maintaining the assurance signal over time. The standard is the same; the procedural infrastructure around it is what makes the certificate procurement-grade.