OWASP API Security Top 10 (2023)
Table of Contents
Quick Answer
The OWASP API Security Top 10 is a ranked list of the most critical security risks in APIs, published by the OWASP API Security Project. The current edition is 2023. Broken Object Level Authorization is ranked first, as it was in 2019, and three of the ten risks are authorization failures. Three risks are new in 2023: abuse of sensitive business flows, server side request forgery, and unsafe consumption of third-party APIs.
This is an independent educational summary written by Insecure Lab. It is not affiliated with or endorsed by OWASP. The official list and its full text are linked under Sources.
The 2023 List
| Risk | In plain terms |
|---|---|
| API1 Broken Object Level Authorization | The API checks that you are logged in, but not that the record you asked for is yours. |
| API2 Broken Authentication | Weaknesses in how the API proves who is calling: tokens, passwords, keys and the flows around them. |
| API3 Broken Object Property Level Authorization | You may access the record, but not every field in it, and the API does not tell the difference. |
| API4 Unrestricted Resource Consumption | No limits on how much work, data or money a single caller can make the API spend. |
| API5 Broken Function Level Authorization | An ordinary user can call an operation that was meant only for administrators or another role. |
| API6 Unrestricted Access to Sensitive Business Flows | The API works exactly as designed, and automation turns that design against the business. |
| API7 Server Side Request Forgery | The API fetches a URL the caller supplied, and can be pointed at systems the caller could never reach directly. |
| API8 Security Misconfiguration | The code may be sound, but the way it is deployed and configured leaves a door open. |
| API9 Improper Inventory Management | You cannot protect an endpoint, version or environment you have forgotten exists. |
| API10 Unsafe Consumption of APIs | Your API trusts the third-party APIs it calls more than it trusts its own users. |
What Changed Since 2019
| Change | Detail |
|---|---|
| New | API6 Unrestricted Access to Sensitive Business Flows, API7 Server Side Request Forgery, API10 Unsafe Consumption of APIs. |
| Merged | Excessive Data Exposure and Mass Assignment became API3 Broken Object Property Level Authorization, because both come from the same missing check. |
| Renamed | Lack of Resources and Rate Limiting became API4 Unrestricted Resource Consumption. Improper Assets Management became API9 Improper Inventory Management. Broken User Authentication became API2 Broken Authentication. |
| Dropped | Injection and Insufficient Logging and Monitoring no longer have their own entries. Both still matter; the list now spends its ten places on risks distinctive to APIs. |
The direction of travel is clear. The 2023 list moves away from implementation bugs and towards design decisions: who may do what, how much, and how far you trust the services you depend on.
API1:2023 Broken Object Level Authorization (BOLA)
Most API endpoints take an object identifier: an order number, an account ID, a document key. Broken object level authorization means the API confirms who the caller is and then returns or changes whichever object was named, without checking that this caller is entitled to that particular object. Changing the identifier in the request is enough to reach someone else's data.
How it shows up. A customer views their own invoice, then requests the same endpoint with a neighbouring invoice number and receives another customer's invoice. Nothing was broken in the login; the check that was missing sits one step later.
How to prevent it
- Check ownership or entitlement on every request that uses a client-supplied identifier, in the data-access layer where it cannot be skipped.
- Derive the user from the session or token, never from a user ID in the request body or path.
- Prefer random, unguessable identifiers, but treat that as friction only; it does not replace the authorization check.
- Write tests that request another user's objects and assert a 403 or 404.
API2:2023 Broken Authentication
Authentication endpoints are exposed to everyone by design, which makes them the most attacked part of any API. This risk covers weak or missing protection on login and password-reset flows, tokens that are not validated properly or never expire, credentials sent in URLs, and API keys used as if they identified a person.
How it shows up. A login endpoint accepts unlimited guesses, a password-reset flow can be driven without proving control of the mailbox, or a service accepts a token without verifying its signature, issuer and expiry.
How to prevent it
- Use a standard, maintained authentication framework; do not design token formats or reset flows from scratch.
- Rate-limit and lock out on authentication endpoints, and treat credential stuffing as the expected case.
- Validate every token fully: signature, algorithm, issuer, audience and expiry. Reject unsigned tokens.
- Keep API keys for identifying applications, and use proper user authentication for identifying people.
API3:2023 Broken Object Property Level Authorization (BOPLA)
Authorization can be correct for the object and still wrong for its properties. This 2023 category merges two older ones: excessive data exposure, where the API returns more fields than the caller should see, and mass assignment, where the API lets the caller write fields they should not control.
How it shows up. A profile endpoint returns the whole user record and relies on the app to hide the internal fields. Or an update endpoint binds the request body straight onto the data model, so adding a role or balance field to the request changes it.
How to prevent it
- Return explicit response objects containing only the fields that caller may see; never serialise the database entity directly.
- Accept an explicit allowlist of writable fields per endpoint and role; never bind request bodies onto internal models.
- Do not rely on the client to filter sensitive data out of a response.
- Validate responses against a schema in tests so an added field does not leak silently.
API4:2023 Unrestricted Resource Consumption
Every request costs something: CPU, memory, bandwidth, storage, and often a per-call charge for an SMS, an email or a third-party lookup. Without limits, one client can exhaust those resources, causing an outage or simply a large bill.
How it shows up. A page-size parameter accepts any number and one request pulls an entire table. An endpoint that sends a verification SMS can be called in a loop. An upload endpoint accepts files of any size.
How to prevent it
- Rate-limit per client and per endpoint, with tighter limits where a call costs money.
- Cap page sizes, payload sizes, upload sizes, array lengths and query complexity on the server.
- Set timeouts and memory limits on the processes that serve requests.
- Put spending limits and alerts on paid third-party services the API calls.
API5:2023 Broken Function Level Authorization (BFLA)
Where BOLA is about which record you may touch, BFLA is about which operations you may perform at all. It appears when administrative and regular functions live side by side and the API assumes that a client which does not show the admin button will never call the admin endpoint.
How it shows up. A regular user changes the HTTP method from GET to DELETE, or swaps a path segment from users to admin, and the request succeeds because only the interface was hiding it.
How to prevent it
- Deny by default, and grant each function to named roles explicitly.
- Enforce the check on the server for every function; hiding a control in the interface is not authorization.
- Keep administrative functions behind a clearly separate route and authorization policy.
- Test each role against every endpoint and method, including the ones that role should never reach.
API6:2023 Unrestricted Access to Sensitive Business Flows
New in 2023. There is no bug here in the usual sense: every request is valid. The harm comes from a legitimate flow being driven at a scale or speed the business did not plan for, such as buying up limited stock, reserving every seat, or creating accounts in bulk to farm a referral bonus.
How it shows up. A ticketing API sells out in seconds to a script, a comment endpoint is used to post spam at volume, or a free-trial flow is automated to create thousands of accounts.
How to prevent it
- Identify which flows would hurt the business if automated, before choosing controls.
- Add friction in proportion to risk: device fingerprinting, human verification, or step-up checks on the sensitive flow only.
- Look for non-human patterns, such as a purchase completed faster than a person could read the page.
- Apply limits per person and per payment method, not only per IP address.
API7:2023 Server Side Request Forgery (SSRF)
New to the API list in 2023. Many APIs fetch remote resources on the caller's behalf: a webhook target, an image to import, a document to preview. If the destination is not validated, the caller can aim that request at internal services, cloud metadata endpoints or other hosts behind the firewall, with the server's network position and trust.
How it shows up. An import-from-URL feature is given an internal address and returns the response, exposing a service that was never meant to be reachable from the internet.
How to prevent it
- Allowlist the destinations, schemes and ports the API may fetch from; blocklists are easy to bypass.
- Resolve the hostname and validate the resulting IP address, and refuse private, loopback and link-local ranges.
- Do not follow redirects automatically, and never return the raw fetched response to the caller.
- Run the fetching component in a network segment with no route to internal services.
API8:2023 Security Misconfiguration
APIs sit on a stack of servers, gateways, frameworks and cloud services, each with its own settings. Misconfiguration covers missing hardening anywhere in that stack: permissive cross-origin rules, verbose error messages, unnecessary HTTP methods, missing transport security, default credentials and unpatched components.
How it shows up. A CORS policy reflects any origin while allowing credentials, a stack trace reveals the framework and file paths, or a debug endpoint is left enabled in production.
How to prevent it
- Build environments from a hardened, repeatable configuration, and keep development and production settings separate.
- Restrict CORS to named origins, and disable HTTP methods the endpoint does not use.
- Return generic error messages to clients and keep the detail in server-side logs.
- Review configuration automatically on every deploy, the same way code is reviewed.
API9:2023 Improper Inventory Management
APIs multiply: old versions kept alive for one client, staging environments reachable from the internet, endpoints added for a partner and never documented. These forgotten surfaces usually miss the patches, rate limits and authentication improvements that the current version received.
How it shows up. Version 1 of an API is still running without the rate limiting added in version 3, or a beta host connected to production data has no authentication at all.
How to prevent it
- Keep an inventory of every API host, version and environment, with an owner and a data classification.
- Generate documentation from the code or the specification so it cannot fall behind.
- Retire old versions on a published schedule, and apply security fixes to every version still running.
- Never connect non-production environments to production data.
API10:2023 Unsafe Consumption of APIs
New in 2023. Teams validate user input carefully and then accept whatever a partner or vendor API returns. An attacker who cannot break your API directly may compromise or impersonate a service you depend on, and have the malicious data delivered through a channel you treat as trusted. AI tools and agents that call external services inherit the same risk.
How it shows up. An address-lookup service is compromised and starts returning crafted values, which the calling API stores and later uses in a query without validation.
How to prevent it
- Validate and sanitise data from third-party APIs exactly as you would user input.
- Call integrations over encrypted channels, and verify who you are talking to.
- Set timeouts and size limits on third-party responses, and do not follow their redirects blindly.
- Assess the security posture of services you depend on, and know what happens to your API if one is compromised.
How to Use the List
- As a review order, not a checklist. It ranks where APIs most often fail. Start with authorization: API1, API3 and API5 are one kind of mistake made at three levels.
- In design reviews. For every new endpoint, ask who may call it, on which records, touching which fields, how often, and what it costs to serve.
- In the test suite. Authorization risks are found by tests that know whose data is whose. Scanners rarely find them.
- Only on systems you may test. Work in development or QA environments, or under written authorisation.
API Security Learning Path
FAQs
Sources and further reading
- OWASP API Security Top 10 - 2023 — The ten risks and their official descriptions
- OWASP API Security Top 10 - 2023 Release Notes — What changed from the 2019 edition
- OWASP API Security Project — Project home
- OWASP Cheat Sheet Series - Authorization — Object, function and property level authorization checks
- OWASP Cheat Sheet Series - REST Security — Practical REST API hardening
- OWASP Cheat Sheet Series - GraphQL — Query depth, complexity limits and authorization for GraphQL APIs
- MITRE CWE-639 - Authorization Bypass Through User-Controlled Key — The weakness behind BOLA; ranked in the 2025 CWE Top 25