OWASP API Security Top 10 (2023) Explained with Examples
APIs now carry most of the traffic behind modern applications: mobile apps, single-page web apps, partner integrations and, increasingly, AI agents all talk to back-end APIs. That makes APIs one of the most attractive targets for attackers, because a single flaw can expose data for every customer at once, often without any visible user interface to hint that something is wrong.
The OWASP API Security Top 10 describes the most critical risks specific to APIs. This guide explains each of the ten categories with examples, prevention advice and how penetration testers look for them.
What Is the OWASP API Security Top 10?
The OWASP API Security Top 10 is published by OWASP’s API Security Project. The first edition appeared in 2019, and the current edition, released in 2023, remains the latest version. Like the main OWASP Top 10, it is an awareness document: a starting point for developers, architects and testers, not a complete standard.
OWASP maintains a separate list for APIs because APIs fail in different ways from traditional web applications. They expose object identifiers and data structures directly, they often return more data than the client displays, and their business logic can be called in any order and at any speed by an automated client.
What Changed in the 2023 Edition
2023 | Category | Change from 2019 |
|---|---|---|
API1 | Broken Object Level Authorization | Still #1 |
API2 | Broken Authentication | Same position |
API3 | Broken Object Property Level Authorization | New; combines the 2019 categories Excessive Data Exposure and Mass Assignment |
API4 | Unrestricted Resource Consumption | Replaces Lack of Resources and Rate Limiting, with a wider focus including costs |
API5 | Broken Function Level Authorization | Same position |
API6 | Unrestricted Access to Sensitive Business Flows | New |
API7 | Server Side Request Forgery | New |
API8 | Security Misconfiguration | Down from #7; injection is now treated as part of this category |
API9 | Improper Inventory Management | Renamed from Improper Assets Management |
API10 | Unsafe Consumption of APIs | New |
API Top 10 vs the OWASP Top 10
The two lists complement each other. The OWASP Top 10 for web applications covers broad application risks such as injection, cryptography and supply chain failures. The API list zooms in on authorization at object, property and function level, abuse of business flows and the risks of managing and consuming many APIs. If your product exposes APIs, use both.
API1:2023 Broken Object Level Authorization (BOLA)
What it is: The API accepts an object identifier from the client, such as an order, invoice or user ID, and returns or modifies that object without checking whether it belongs to the caller. It is the API version of IDOR, and the most common serious API flaw.
Example:
GET /api/v2/invoices/48213 ← your invoice
GET /api/v2/invoices/48214 ← someone else's invoice, returned with HTTP 200The request is perfectly valid and authenticated, which is why scanners rarely notice. Only a test that compares what different users are allowed to see reveals the flaw.
Prevention: check object ownership on the server for every request that uses an identifier, ideally through a central authorization layer; never rely on the client to send only its own IDs; use random, non-sequential identifiers as defense in depth, not as the fix.
API2:2023 Broken Authentication
What it is: Weaknesses in how the API identifies callers, letting attackers impersonate users or other services.
Common forms: no rate limiting on login or one-time code endpoints; JWTs accepted without signature validation, with the none algorithm or with weak signing keys; long-lived tokens that are never revoked; API keys sent in URLs; and password reset flows that can be abused.
Prevention: use standard, well-tested authentication (for example OAuth 2.0 and OpenID Connect) rather than custom schemes; validate every token’s signature, issuer, audience and expiry; protect authentication endpoints with rate limiting and lockout; and require re-authentication for sensitive operations.
API3:2023 Broken Object Property Level Authorization
What it is: The caller is allowed to access an object, but not every property of it. This new category merges two 2019 risks:
- Excessive data exposure: the API returns more fields than the client needs, such as internal flags, other users’ contact details or password hashes, trusting the front end to hide them.
- Mass assignment: the API binds every field in the request to the object, so a user can set properties they should not control, such as
"role": "admin"or"balance": 99999.
Real-world example: In 2012, a security researcher used a mass assignment weakness in GitHub, built on Ruby on Rails, to add his own key to the Rails project’s repository, demonstrating that a property users should never control could be set simply by including it in a request. The incident pushed Rails to change how it handled mass assignment by default.
Prevention: return only the fields each client needs, defined by explicit response schemas; use allowlists of writable properties for each endpoint and role; never bind request bodies directly to database models.
API4:2023 Unrestricted Resource Consumption
What it is: The API does not limit how much a caller can consume: requests, data, processing time or paid third-party services. The result can be denial of service, but increasingly it is a financial problem.
Common forms: no rate limits or quotas; unlimited page sizes such as ?limit=1000000; expensive GraphQL queries with deep nesting or batching; uploads without size limits; and endpoints that trigger paid actions, such as sending SMS or emails, without restriction. Abusing an unprotected “send verification code” endpoint to generate large volumes of SMS messages, sometimes called SMS pumping, is a typical example of the cost side of this risk.
Prevention: apply rate limits and quotas per user, API key and IP; enforce maximum page sizes, payload sizes and execution timeouts; limit GraphQL query depth and complexity; and set spending limits on third-party integrations.
API5:2023 Broken Function Level Authorization
What it is: Users can call functions they should not have access to, typically administrative endpoints. Where BOLA is about which objects you can access, BFLA is about which actions you can perform.
Example: the mobile app only shows administrator features to admins, but the API endpoint behind them, such as DELETE /api/users/{id} or /api/admin/export, only checks that the caller is logged in. Any user who discovers the endpoint can use it.
Prevention: deny by default and grant access to functions explicitly by role; enforce authorization on the server for every endpoint, including those not shown in the user interface; keep administrative APIs separate where possible.
API6:2023 Unrestricted Access to Sensitive Business Flows
What it is: A new category for abuse of legitimate functionality at scale. Nothing is technically broken; the problem is that a business flow can be automated in a way that harms the business.
Examples: bots buying limited stock or event tickets the moment they go on sale and reselling them; mass account creation to abuse sign-up bonuses or referral programs; automated reservation of appointments or inventory without completing the purchase; and scraping prices or content at scale.
Prevention: identify which flows are sensitive to automation; use device fingerprinting, behavioral signals or challenges such as CAPTCHA where appropriate; apply per-user and per-flow limits; and monitor for unusual patterns.
API7:2023 Server Side Request Forgery (SSRF)
What it is: The API fetches a resource from a URL supplied by the user, such as a webhook, an image import or a document preview, and an attacker uses it to make the server send requests to internal systems that are not reachable from the internet.
Real-world example: The 2019 Capital One breach is widely cited as an SSRF case: an attacker abused a misconfigured web application firewall to make requests to the cloud metadata service, obtained temporary credentials and used them to access stored customer data.
Prevention: validate and restrict user-supplied URLs with allowlists of permitted destinations; block requests to internal and link-local address ranges, including cloud metadata endpoints; disable unnecessary redirects; and in cloud environments, enforce the more secure metadata service versions (such as IMDSv2 on AWS).
API8:2023 Security Misconfiguration
What it is: Insecure settings anywhere in the API stack. In 2023, injection flaws are treated as part of this category for APIs.
Common forms: permissive CORS policies that let any website call the API with a user’s credentials; verbose error messages exposing stack traces or queries; missing TLS or security headers; unnecessary HTTP methods enabled; debug endpoints or GraphQL introspection left enabled in production; and unvalidated input passed to database queries or system commands.
Prevention: use hardened, automated configuration across environments; restrict CORS to known origins; return generic errors; disable introspection and debug features in production where not needed; and use parameterized queries. Our GitLab GraphQL vulnerability analysis shows how an injection flaw can be reached through a GraphQL API.
API9:2023 Improper Inventory Management
What it is: The organization does not know exactly which APIs, versions and environments it exposes. Forgotten APIs are rarely patched or monitored.
Common forms: old API versions, such as /v1/, still running alongside /v2/ without the same security fixes; test or staging APIs reachable from the internet with real data; undocumented “shadow” endpoints created by teams outside the main process; and missing documentation of which data flows to which third parties.
Prevention: maintain an inventory of every API, version, environment and data flow, ideally generated automatically from gateways and specifications such as OpenAPI; retire old versions on a schedule; and apply the same protections to non-production environments that hold real data.
API10:2023 Unsafe Consumption of APIs
What it is: Your API trusts data received from third-party APIs more than data from users, and processes it without validation. If the third party is compromised or returns unexpected data, your system inherits the problem.
Common forms: following redirects from a third-party API blindly; passing third-party responses into queries or templates without validation; no timeouts or limits on third-party responses; and communicating with integrations over unencrypted channels.
Prevention: treat third-party data as untrusted input; validate and sanitize responses against expected schemas; use TLS for all integrations; set timeouts and size limits; and assess the security of the APIs you depend on.
How to Test Your APIs Against the OWASP API Top 10
Automated scanners help with configuration issues and some injection flaws, but most of the API Top 10 is about authorization and business logic, which requires a tester who understands how the API is meant to work. A typical API penetration test includes:
- Discovery and inventory: collecting OpenAPI or GraphQL schemas, mapping endpoints from client traffic and looking for undocumented, old or test endpoints (API9).
- Authentication review: testing token handling, JWT validation, session lifetime and protection of login and reset flows (API2).
- Authorization testing with multiple accounts: replaying every request with another user’s identifiers and with lower-privileged roles, at object, property and function level (API1, API3, API5).
- Abuse and limits: checking rate limits, pagination, payload sizes, GraphQL query depth and sensitive business flows (API4, API6).
- Input and integration testing: injection, SSRF through URL parameters and webhooks, and handling of third-party data (API7, API8, API10).
- Reporting: documenting each finding with requests, responses and business impact. See what to expect in a penetration test report.
During development, add automated API security checks to your CI/CD pipeline and contract tests that verify authorization rules for each role. Our guide to shift left security explains how these fit together.
Frequently asked questions
Conclusion
API security failures are rarely about exotic exploits. They are about missing ownership checks, fields returned or accepted without control, functions exposed to the wrong roles and business flows that can be automated at scale. The OWASP API Security Top 10 gives development and security teams a shared vocabulary for these risks, but finding them in practice requires testing that understands your API’s logic.
Want to know whether your APIs are exposed? Explore our API Security Testing service, or train your developers and testers with our API Security Testing Training. Talk to our team to get started.
Subscribe to our cyber security newsletter