OWASP API Security Top 10

1. Introduction

Application Programming Interfaces (APIs) have become the connective tissue of modern digital business. Mobile applications, single-page web front-ends, business-to-business integrations, microservices, partner ecosystems and Internet-of-Things devices all communicate through APIs. Because APIs expose application logic and sensitive data directly, and because they are increasingly automated and machine-to-machine, they have become the single largest attack surface for many organisations. The OWASP API Security Top 10 is the industry-recognised reference that catalogues the most critical security risks specific to APIs, distinct from the general-purpose OWASP Top 10 for web applications.

This guide is written from the perspective of an assessor who must independently verify whether an organisation's APIs are designed, built, deployed and operated in a way that mitigates the risks enumerated in the OWASP API Security Top 10 (2023 edition). It provides a master assessment checklist covering every one of the ten risk categories, the evidence an auditor should collect, a phased implementation approach, a maturity model, mappings to adjacent frameworks, and practical readiness tooling. It is intended for security architects, API product owners, DevSecOps engineers, penetration testers and governance, risk and compliance (GRC) teams.

2. What is the OWASP API Security Top 10

The OWASP API Security Top 10 is a prioritised, consensus-driven list of the ten most serious security risks affecting APIs. It was first published as a dedicated project in 2019 in recognition that APIs have unique threat characteristics that the classic web-application Top 10 did not fully address. The current edition, released in 2023, refines and reorders the categories based on real-world breach data, bug-bounty findings and practitioner input gathered by the OWASP community.

Unlike a formal certifiable standard such as ISO/IEC 27001 or PCI DSS, the OWASP API Security Top 10 is an awareness and prioritisation document rather than a compliance regime. There is no certificate of conformance. Its purpose is to focus limited security effort on the risks that matter most, to establish a shared vocabulary between developers and security teams, and to serve as the backbone of secure-development training, threat modelling, code review, and dynamic and static testing programmes. It is frequently cited as a baseline expectation inside contracts, secure-SDLC policies and vendor security questionnaires.

The ten 2023 categories are: API1:2023 Broken Object Level Authorization (BOLA); API2:2023 Broken Authentication; API3:2023 Broken Object Property Level Authorization; API4:2023 Unrestricted Resource Consumption; API5:2023 Broken Function Level Authorization; API6:2023 Unrestricted Access to Sensitive Business Flows; API7:2023 Server Side Request Forgery (SSRF); API8:2023 Security Misconfiguration; API9:2023 Improper Inventory Management; and API10:2023 Unsafe Consumption of APIs. A recurring theme is authorisation: the majority of the list concerns granting access to the wrong object, property, function or business flow.

3. Who must comply

Because the OWASP API Security Top 10 is a best-practice reference rather than a legal mandate, no organisation is legally compelled to 'comply' with it by name. In practice, however, it is treated as a de facto minimum bar for any organisation that exposes or consumes APIs, and it is routinely invoked by regulators, auditors and enterprise buyers as evidence of due diligence. The following table sets out the parties who should adopt it and why.

4. Structure of the OWASP API Security Top 10

The 2023 edition is organised as ten discrete risk categories, each identified by an APIx:2023 code, a descriptive name and a short-hand acronym where applicable. Categories are ordered by a composite of exploitability, prevalence, detectability and technical/business impact. The table below presents the complete structure with the dominant weakness class each category represents.

5. Master assessment checklist

This is the core of the guide. Each of the ten categories is treated as an assessment domain with its own subsection. For every domain the auditor is given a set of verification points ('What to verify') and the artefacts that typically satisfy each point ('Typical evidence'). An assessment should not be considered complete unless every domain below has been walked through against every in-scope API. Verification points are written so they can be tested through documentation review, code and configuration inspection, interviews, and dynamic testing.

API1:2023 — Broken Object Level Authorization (BOLA)

BOLA occurs when an API endpoint receives an object identifier and returns or modifies that object without confirming the caller is entitled to it. It is the single most common and impactful API flaw, enabling horizontal privilege escalation and mass data extraction by iterating identifiers.

API2:2023 — Broken Authentication

Authentication weaknesses allow attackers to assume other identities. This includes weak credential policies, flawed token issuance and validation, missing brute-force protection, and insecure password-reset and account-recovery flows.

API3:2023 — Broken Object Property Level Authorization

This category merges the former 'Excessive Data Exposure' and 'Mass Assignment' risks. It concerns authorisation at the level of individual object properties: returning fields the caller should not see (read side) or allowing the caller to write fields they should not modify (write side).

API4:2023 — Unrestricted Resource Consumption

APIs consume compute, memory, storage, bandwidth and paid third-party services (SMS, email, cloud functions). Without limits, attackers can cause denial of service or drive up costs ('denial of wallet').

API5:2023 — Broken Function Level Authorization

Where BOLA concerns access to data objects, BFLA concerns access to functions and operations. It arises when an endpoint or HTTP method (for example an administrative DELETE) is reachable by users who lack the necessary role or privilege.

API6:2023 — Unrestricted Access to Sensitive Business Flows

This category addresses business-logic abuse: sensitive workflows (purchasing limited stock, creating accounts, posting comments, redeeming rewards) that are technically 'authorised' but harmful when performed at scale by automation or bots.

API7:2023 — Server Side Request Forgery (SSRF)

SSRF occurs when an API fetches a remote resource using a URL supplied or influenced by the client without validating it, allowing attackers to make the server issue requests to internal systems, cloud metadata endpoints or arbitrary hosts.

API8:2023 — Security Misconfiguration

Misconfiguration spans the entire stack: missing hardening, verbose error messages, permissive CORS, absent security headers, unpatched components, default credentials and unnecessary features left enabled.

API9:2023 — Improper Inventory Management

Organisations cannot protect APIs they do not know about. This category covers unknown, deprecated, shadow and zombie APIs, unmanaged versions, and undocumented environments that widen the attack surface.

API10:2023 — Unsafe Consumption of APIs

Developers often trust data from third-party or upstream APIs more than direct user input. This category addresses the risks of consuming external APIs without applying the same validation, transport security and error-handling discipline.

6. Scoping

Scoping determines which API assets are subject to assessment and to what depth. Because the OWASP API Security Top 10 is risk-based rather than certification-based, scope should be driven by exposure and data sensitivity rather than an arbitrary boundary. A well-scoped engagement prevents both under-coverage (leaving shadow APIs untested) and wasted effort (deeply testing low-value internal utilities).

• Enumerate all API assets first: public, partner, internal/east-west, mobile back-ends, GraphQL and gRPC services, webhooks and third-party integrations consumed.
• Classify each API by data sensitivity (regulated, personal, financial, public) and by exposure (internet-facing, partner-restricted, internal only).
• Prioritise internet-facing APIs handling sensitive or regulated data for the deepest testing, including authenticated multi-role dynamic testing.
• Include non-production environments that are reachable, as staging and debug endpoints are a recognised API9 risk.
• Define which roles and tenants are available for authorisation testing (essential for BOLA and BFLA coverage).
• Explicitly note out-of-scope systems and the residual risk their exclusion carries.
• Confirm testing windows, rate-limit exemptions and rollback plans for any active dynamic testing against production.

7. Implementation approach

Mitigating the OWASP API Security Top 10 is a programme, not a one-off scan. The following phased approach embeds API security across the software development lifecycle and operations. Each phase lists indicative activities and the deliverables an auditor would expect to see.

Phase 1 — Discover and inventory

Activities: run automated API discovery against traffic, gateways and code repositories; build a central API catalogue; classify data sensitivity and exposure; identify shadow, deprecated and zombie APIs. Deliverables: authoritative API inventory, data classification, exposure map, and a prioritised backlog of unmanaged APIs to remediate (directly addressing API9).

Phase 2 — Threat model and design controls

Activities: threat-model high-value APIs and sensitive business flows; define authorisation model (object, property and function level); establish secure-by-default patterns, standard authentication, and reference architectures. Deliverables: threat models, authorisation matrices, secure API design standards, and abuse-case catalogues (addressing API1, API3, API5 and API6).

Phase 3 — Build securely

Activities: implement centralised authorisation middleware, allow-list request binding, response DTO filtering, input validation, rate limiting and SSRF protection; integrate SAST and SCA into CI. Deliverables: reusable security libraries, hardened gateway configuration, dependency scan gates, and secure-coding training records.

Phase 4 — Test and validate

Activities: run DAST and dedicated API security testing (including BOLA/BFLA fuzzing with multiple roles and tenants), business-logic and authentication testing, and third-party integration reviews. Deliverables: test plans, penetration test reports, CI security test evidence, and a triaged findings register.

Phase 5 — Deploy and harden

Activities: apply configuration baselines through infrastructure as code; enforce TLS, CORS, headers and error hygiene; disable debug endpoints; validate egress controls. Deliverables: IaC-managed hardening baseline, configuration compliance reports, and a pre-production security gate (addressing API8).

Phase 6 — Operate and monitor

Activities: deploy API-aware runtime protection (WAAP/gateway monitoring), anomaly and abuse detection, quota and cost monitoring, and a vulnerability/patch management cadence; maintain inventory currency. Deliverables: monitoring dashboards, alerting rules, incident response playbooks, and periodic re-assessment schedule.

8. Maturity and capability model

Because there is no formal scoring scheme in the OWASP API Security Top 10 itself, organisations benefit from a capability maturity model to gauge and communicate progress. The five-level model below can be applied per risk category or to the API security programme as a whole.

9. Assessment and audit approach

An assessment against the OWASP API Security Top 10 combines documentation review, technical testing and interviews. The following ordered steps describe a defensible audit methodology.

1. Agree scope, rules of engagement and testing windows; obtain necessary authorisations and test credentials for multiple roles and tenants.
2. Obtain and validate the API inventory and documentation (OpenAPI specs); identify undocumented or shadow endpoints through discovery (covers API9).
3. Review the authorisation architecture and perform object-level, property-level and function-level access testing across roles and tenants (API1, API3, API5).
4. Assess authentication and session/token handling, including brute-force protection and token validation (API2).
5. Test resource consumption controls: rate limits, payload and query complexity limits, and cost controls (API4).
6. Analyse sensitive business flows for automation and abuse resistance (API6).
7. Test server-side request handling for SSRF and review egress controls (API7).
8. Review configuration, headers, CORS, error handling and dependency hygiene across environments (API8).
9. Review consumption of third-party APIs for validation, transport security and error handling (API10).
10. Consolidate findings, rate them by risk, map each to its OWASP category, and produce a prioritised remediation roadmap with retest criteria.

10. Evidence request list

The following categorised artefacts should be requested at the outset of an assessment to support efficient, evidence-based verification.

• Governance and inventory: API catalogue/registry, data classification, exposure map, deprecation and versioning policy.
• Documentation: OpenAPI/Swagger specifications, architecture and data-flow diagrams, threat models and abuse-case catalogues.
• Authorisation and authentication: RBAC/ABAC policies, authorisation middleware code, IdP/OAuth configuration, MFA policy, token validation configuration.
• Configuration: gateway and WAF/WAAP configuration, rate-limit and quota policies, CORS and security-header configuration, TLS scan reports, IaC hardening baselines.
• Development assurance: secure-coding standards, SAST/DAST/SCA reports, CI security-gate evidence, code-review records, training records.
• Testing: penetration test reports (including BOLA/BFLA testing), business-logic test results, and the current findings/remediation register.
• Third-party: integration inventory, vendor security assessments, and contractual security clauses.
• Operations: monitoring dashboards, anomaly/abuse alert rules, incident response playbooks, patch and vulnerability management records.

11. Roles and responsibilities

Clear ownership is essential; API security spans product, engineering, security and operations. The RACI-style table below sets out typical accountabilities.

12. KPIs to track

• Percentage of APIs inventoried and documented against the estimated total (inventory coverage).
• Percentage of endpoints covered by automated authorisation (BOLA/BFLA) tests in CI.
• Number of shadow, deprecated or zombie APIs discovered and time to decommission.
• Mean time to remediate high and critical API findings.
• Percentage of APIs behind enforced rate limiting and quotas.
• Number of API security findings by OWASP category over time (trend by risk).
• Percentage of third-party integrations with completed security assessments.
• Proportion of APIs conforming to the configuration hardening baseline.
• Rate of abuse/anomaly alerts on sensitive business flows and time to response.

13. Readiness checklist

• A complete, current inventory of all APIs, versions and environments is maintained.
• Every endpoint enforces server-side object-level authorisation tied to the authenticated identity (API1).
• Authentication is hardened with rate limiting, robust token validation and MFA on sensitive operations (API2).
• Responses filter sensitive properties and writes use allow-list binding (API3).
• Rate limits, payload/query complexity limits and cost controls are enforced (API4).
• Privileged functions and HTTP methods enforce role checks with deny-by-default (API5).
• Sensitive business flows have anti-automation and business-rule limits (API6).
• Server-side URL fetches are validated and egress to internal ranges/metadata is blocked (API7).
• A hardened configuration baseline, secure headers, restricted CORS and clean error handling are applied across environments (API8).
• Deprecated versions are decommissioned and non-production environments are not exposed (API9).
• Third-party API data is validated and consumed over TLS with defensive error handling (API10).
• Automated API security testing runs in CI and periodic penetration testing is scheduled.
• Runtime monitoring, anomaly detection and incident playbooks are in place.

14. Common gaps

• Authorisation checks that trust client-supplied object identifiers, leading to BOLA and mass data extraction.
• Filtering sensitive fields in the client or UI rather than server-side, leaving full data in API responses.
• Accepting arbitrary request bodies without allow-list binding, enabling mass assignment of privileged fields.
• Rate limiting applied only globally at the perimeter rather than per user, per client and per endpoint.
• Admin functions distinguished only by an unlinked URL path, discoverable through forced browsing (BFLA).
• No threat modelling of business flows, leaving them open to automated abuse and inventory hoarding.
• URL-fetching features without allow-lists or egress controls, exposing cloud metadata and internal services to SSRF.
• Verbose error messages, permissive wildcard CORS with credentials, and missing security headers.
• Forgotten staging, debug and old-version endpoints exposed to the internet with weaker controls.
• Blind trust in third-party API responses without validation, safe redirect handling or TLS verification.

15. OWASP API Security Top 10 mapped to other frameworks

The OWASP API Security Top 10 is not a standalone compliance regime; it operationalises the secure-development and vulnerability-management expectations found in broader frameworks. The mapping below shows how each category supports adjacent controls. Mappings are indicative and should be tailored per assessment.

16. How CyberSigma helps

Frequently asked questions

Need help with OWASP API Top 10?

CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.