OWASP API Security Top 10 (2023): A Cloud-Native Guide for Security Teams

Key Takeaways

• The OWASP API Security Top 10 ranks the most critical API security risks and provides practical guidance for reducing them.
• Broken Object Level Authorization (BOLA) remains the number-one risk, and most of the top categories stem from authorization failures rather than vulnerabilities a firewall can detect.
• The current 2023 edition renamed several categories, merged Excessive Data Exposure and Mass Assignment into BOPLA, and added SSRF, Unsafe Consumption of APIs, and Unrestricted Access to Sensitive Business Flows.
• You cannot secure APIs you cannot see. Improper Inventory Management (API9) makes maintaining an accurate inventory of active, shadow, and deprecated APIs a foundational security practice.
• Orca discovers every web and API endpoint agentlessly, correlates each finding with the surrounding cloud risk, and prioritizes the APIs that create real attack paths.

The OWASP API Security Top 10 is OWASP’s ranked list of the most critical security risks affecting APIs. It provides a practical framework for identifying common weaknesses, prioritizing remediation, and building more secure APIs. The current edition is the 2023 release, which supersedes the 2019 version and remains the latest guidance available.

APIs now carry the traffic, business logic, and sensitive data that once sat behind web applications, and cloud-native environments create new endpoints continuously. This guide explains each OWASP API Security Top 10 category, highlights what changed in the 2023 update, and outlines practical prevention strategies for cloud and multi-cloud environments.

What Is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a standard awareness document that ranks the ten most critical security risks to application programming interfaces (APIs). The Open Worldwide Application Security Project (OWASP) publishes it through the OWASP API Security Project, a community effort that maintains the list from real-world API breach and bug-bounty data.

OWASP first published the API list in 2019 because the general OWASP Top 10 for web apps did not capture how APIs fail, and released the current 2023 edition after four years of new data. Each risk carries an identifier (API1 through API10), so teams treat the list as a testing and prioritization baseline. It names where to look first and gives AppSec and platform teams a shared vocabulary for API risk.

OWASP API Security Top 10 vs. the OWASP Top 10 (web apps)

The two lists overlap but solve different problems. The general OWASP Top 10 covers web application risks such as injection and broken access control. The API list targets the object, property, and function-level authorization logic that APIs expose directly to callers, plus API-specific risks like Improper Inventory Management and Unsafe Consumption of APIs.

Some categories appear on both, including broken access control, misconfiguration, and SSRF. The difference is depth: an API returns raw data and accepts structured input with no UI to constrain the caller, so authorization flaws a web front end would hide become directly exploitable. The API list complements the 2025 OWASP Top 10 for web apps by focusing on API-specific attack surfaces and the API security fundamentals that govern communication behind the endpoint.

Why API Security Risks Are Escalating in the Cloud

API risk is escalating because cloud-native architecture multiplies the number of APIs, and the sensitive data behind them, faster than security teams can track. Every microservice, managed database, message queue, and model endpoint ships its own API, and CI/CD releases new ones continuously.

Three shifts drive the exposure:

• Decomposition: One monolith becomes dozens of internal and external APIs, each creating a new entry point.
• Sprawl: Shadow APIs, zombie APIs left running after version changes, and deprecated endpoints with weaker authentication silently expand the attack surface.
• Automation: Attackers script authorization abuse and credential-stuffing attacks against APIs at machine speed, so a single BOLA flaw can be exploited across thousands of records.

Traditional perimeter defenses were built for web applications and cannot see whether an API request is authorized or follow east-west traffic between services. As APIs have become a primary attack target, Akamai documented 150 billion API attacks between January 2023 and December 2024. The OWASP API Security Top 10 highlights the weaknesses attackers exploit most often.

The OWASP API Security Top 10 (2023 Edition)

The 2023 edition ranks the ten risks below by prevalence and impact, drawn from OWASP’s analysis of real API incidents. Authorization failures dominate the top of the list.

API1:2023: Broken Object Level Authorization (BOLA)

BOLA is the top API risk: an endpoint exposes an object by its identifier but never checks that the caller owns it. It ranked first in 2019 and stayed first in 2023.

An attacker calls GET /api/orders/123, changes the ID to 124, and reads another tenant’s order. No exploit kit is needed, only an incremented value, which is why automated tools harvest records fast. Prevent it by enforcing an object-level authorization check on every request that carries an ID, validating ownership from the server-side session rather than a client claim, and using random, non-sequential identifiers such as UUIDs so IDs cannot be guessed.

API2:2023: Broken Authentication

Broken Authentication covers weak, missing, or improperly implemented authentication that lets an attacker assume another identity or forge tokens.

Common paths include credential stuffing against a login endpoint with no rate limit, a JWT signed with a weak or hardcoded secret, and a password-reset flow that leaks or reuses tokens. Prevent it by adopting standard protocols such as OAuth 2.0 and OpenID Connect instead of hand-rolled auth, enforcing multi-factor authentication and short-lived signed tokens, and rate-limiting every authentication endpoint. Treat authentication tokens as secrets and rotate signing keys.

API3:2023: Broken Object Property Level Authorization (BOPLA)

BOPLA is a new 2023 category that merges two 2019 risks, Excessive Data Exposure and Mass Assignment. The API authorizes access to an object but not to its individual properties, so a caller reads or writes fields they should not touch.

On the read side, a profile response returns a Social Security number the client never displays but an attacker can capture. On the write side, a PATCH request sets "role": "admin" on the caller’s own account. Prevent it by validating authorization per property, returning only fields the caller is entitled to, and allowlisting writable fields instead of binding request bodies straight to internal objects.

API4:2023: Unrestricted Resource Consumption

Renamed from Lack of Resources and Rate Limiting, this risk covers APIs that place no limit on the compute, memory, bandwidth, or third-party spend a request can trigger.

An attacker floods an endpoint to exhaust resources, or drives cost-based denial of service by forcing metered downstream calls such as SMS, email, or cloud egress. A deeply nested GraphQL query can amplify one request into thousands of resolver calls. Prevent it with rate and concurrency limits, request-size and query-depth caps, pagination limits, execution timeouts, and billing alerts on metered services the API calls.

API5:2023: Broken Function Level Authorization (BFLA)

BFLA happens when an API authenticates the caller but does not enforce which functions or roles that caller may invoke.

A standard user discovers and calls an administrative route such as DELETE /api/admin/users/42, escalating privilege vertically, or reaches a peer’s function horizontally. Administrative endpoints are often guessable from predictable naming conventions. Prevent it by denying access by default, enforcing role-based access control (RBAC) or attribute-based checks at the function level, and centralizing that authorization logic rather than reimplementing it in each handler.

API6:2023: Unrestricted Access to Sensitive Business Flows

A new 2023 entry, this risk covers automated abuse of a legitimate business flow, such as purchasing, booking, or account creation, without relying on a technical vulnerability.

Bots buy the entire stock of a limited release in seconds to resell it, or mass-create accounts to run fraud and spam. The API works as designed; the harm comes from the volume and intent. Prevent it by identifying which flows are sensitive, then adding controls the attacker cannot easily script, including bot and device detection, step-up verification, and business-logic-aware throttling rather than a per-endpoint rate limit alone.

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

New in 2023, SSRF occurs when an API fetches a remote resource from a user-supplied URL without validating it, so an attacker makes the server issue requests on their behalf.

The highest-impact cloud scenario points that URL at the instance metadata endpoint, 169.254.169.254, to steal temporary credentials and pivot deeper into the environment. As cloud-native applications became increasingly common, SSRF emerged as a distinct API security risk and was added to the 2023 list. Orca’s research team has repeatedly identified SSRF flaws exposing cloud metadata across major providers. Prevent it by allowlisting outbound destinations, blocking link-local and internal IP ranges, enforcing IMDSv2 on AWS, and disabling unused URL schemes and redirects.

API8:2023: Security Misconfiguration

Security Misconfiguration covers insecure defaults, incomplete hardening, verbose errors, missing security headers, and permissive settings anywhere in the API stack.

A CORS policy that allows any origin, a debug endpoint left enabled in production, or an unpatched API framework each opens a path in. In the cloud, the misconfiguration often sits in the infrastructure around the API, not the code. Prevent it by automating hardened configuration baselines, disabling debug and verbose errors in production, patching frameworks on a schedule, and scanning for drift. Many of these overlap with the common cloud misconfigurations that expose services directly.

API9:2023: Improper Inventory Management

Renamed from Improper Assets Management, this risk is the visibility gap: you cannot protect API hosts and endpoints you have not inventoried. Shadow, zombie, and deprecated APIs are the usual culprits.

An old /v1 endpoint stays live after /v3 ships, unpatched and with weaker authentication, or a staging API is exposed to the internet and forgotten. Attackers find these before defenders do. Prevent it by maintaining a continuous, complete inventory of every API across every environment, documenting each host, version, and data flow, and formally retiring deprecated versions. This is where continuous, agentless discovery becomes essential.

API10:2023: Unsafe Consumption of APIs

The final new 2023 entry addresses the APIs your API consumes. Teams tend to trust data from third-party and upstream integrations more than direct user input, so a compromised partner flows straight through.

If an upstream API is breached and returns malicious payloads, or your service follows its redirects blindly, the trust becomes the vulnerability. Prevent it by treating every third-party response as untrusted input: validate and sanitize it, enforce TLS on integration traffic, evaluate the security of the APIs you depend on, and avoid blindly following redirects to unvalidated destinations.

What Changed from the 2019 to the 2023 OWASP API Security Top 10

The 2023 edition kept the authorization risks at the top, renamed several categories for clarity, merged two into one, dropped two standalone entries, and added four new risks. The table maps each 2019 category to its 2023 status.

2019 category	2023 category	Status
API1 Broken Object Level Authorization	API1 Broken Object Level Authorization	Unchanged
API2 Broken User Authentication	API2 Broken Authentication	Renamed
API3 Excessive Data Exposure	API3 Broken Object Property Level Authorization	Merged
API6 Mass Assignment	API3 Broken Object Property Level Authorization	Merged
API4 Lack of Resources & Rate Limiting	API4 Unrestricted Resource Consumption	Renamed
API5 Broken Function Level Authorization	API5 Broken Function Level Authorization	Unchanged
(no 2019 equivalent)	API6 Unrestricted Access to Sensitive Business Flows	New
(no 2019 equivalent)	API7 Server-Side Request Forgery	New
API7 Security Misconfiguration	API8 Security Misconfiguration	Unchanged
API8 Injection	Folded into Security Misconfiguration guidance	Removed
API9 Improper Assets Management	API9 Improper Inventory Management	Renamed
API10 Insufficient Logging & Monitoring	No direct successor	Removed
(no 2019 equivalent)	API10 Unsafe Consumption of APIs	New

Three changes stand out. Broken Object Property Level Authorization (BOPLA) combines the former Excessive Data Exposure and Mass Assignment categories to better reflect property-level authorization flaws. Server-Side Request Forgery (SSRF) was added as cloud-native architectures made metadata-service attacks and backend request abuse more common. Meanwhile, Injection and Insufficient Logging & Monitoring are no longer standalone categories, although the underlying risks remain covered elsewhere in the framework.

The 2023 edition remains the current OWASP API Security Top 10. Despite frequent searches for a “2025” version, OWASP has not published a newer edition, so organizations should continue using the 2023 guidance until the framework is updated.

How to Prevent OWASP API Security Risks: Best Practices

Preventing the OWASP API risks comes down to five practices that map across the list. Start with inventory, because every other control depends on knowing which APIs exist.

Discover and inventory every API (shadow, zombie, deprecated)

A complete API inventory is the prerequisite for the whole list and the direct fix for API9. You cannot apply authorization, rate limits, or patches to an endpoint you do not know is running.

Discover APIs continuously across every account and environment, not once a quarter from a spreadsheet. Capture each host, version, exposure, and the sensitive data it handles, then retire deprecated versions on a schedule so zombie endpoints do not linger. Prioritize internet-exposed and unauthenticated APIs first, since those are what attackers enumerate.

Enforce authentication & authorization (RBAC/ABAC, least privilege, MFA)

Authorization failures make up API1, API2, API3, and API5, so this is the highest-leverage control area. Authentication proves who is calling; authorization decides what that caller may reach, per object and per function.

Enforce object-level and function-level checks on the server for every request, deny by default, and apply least privilege so a token grants only what its owner needs. Use RBAC or attribute-based access control, standard auth protocols, and multi-factor authentication on sensitive flows. Do not trust an ID or role asserted by the client.

Rate limiting & resource controls

Rate and resource limits blunt API4 and API6 by capping how much damage automation can do. Without them, one endpoint absorbs a flood or drives runaway third-party cost.

Set per-client rate and concurrency limits, request-size and query-depth caps, timeouts, and pagination limits. Add spend alerts on any metered downstream service the API calls. For sensitive business flows, layer bot detection on top, since a plain rate limit does not distinguish a scalping bot from a busy customer.

Shift-left API security testing in CI/CD

Testing APIs before they ship catches BOLA, BFLA, and misconfiguration while they are cheap to fix. A new endpoint should not reach production untested. Integrate shift-left security testing into the pipeline. 

Generate and lint an OpenAPI specification, run authorization and fuzzing tests against object- and function-level access, and scan infrastructure-as-code and container images for the misconfigurations that surface as API8. Fail the build on high-severity findings, then feed results back to the owning team with the exact line to fix.

Continuous monitoring & runtime protection (WAF/WAAP/API gateway in context)

Runtime controls catch what testing misses and detect abuse in progress. An API gateway, a web application firewall (WAF), or a broader web application and API protection (WAAP) layer enforces authentication, rate limits, and schema validation at the edge.

These tools are necessary but not sufficient. A WAF inspects requests without knowing whether the caller owns object 124 or which identities and data sit behind the endpoint. Pair edge enforcement with posture context that connects an API finding to the workload, identity, and data around it, so alerts reflect real exposure rather than raw request volume.

Securing APIs Across Multi-Cloud with Orca

Orca helps security teams apply the OWASP API Security Top 10 across multi-cloud environments by combining complete API visibility with attack-path prioritization. Using patented SideScanning™, Orca’s agentless technology discovers web and API endpoints across AWS, Azure, and Google Cloud without deploying agents on individual workloads, helping teams identify shadow, zombie, and deprecated APIs before they become blind spots.

Orca then correlates every API finding with the surrounding cloud context, including vulnerabilities, misconfigurations, identities, and sensitive data, to prioritize the risks that are actually exploitable. Instead of generating isolated alerts, Orca maps API exposures into complete attack paths so security teams know what to remediate first. Explore API security capabilities or get a demo to see how Orca helps secure APIs across your cloud environment.

Frequently Asked Questions about OWASP API Security