OWASP API Security Top 10: Risks, Examples, and Controls for 2023

The OWASP API Security Top 10 2023 is an awareness document for security risks that appear frequently in application programming interfaces. Its categories cover object and function authorization, authentication, object properties, resource consumption, sensitive business flows, server-side request forgery, configuration, inventory, and trust in upstream APIs.

The 2023 edition is still the current stable release on the OWASP API Security Project. OWASP states that the list is forward-looking and does not replace the web application Top 10 or a risk assessment for a particular API. A mobile, web, or agent application may need both its domain-specific list and the API list.

The strongest theme is authorization. Three of the first five entries concern whether a caller may reach an object, property, or function. An API can authenticate every request correctly and still expose another customer’s records or allow an ordinary account to call an administrative operation.

Key Takeaways

• Test object, property, and function authorization independently because each failure exposes a different part of an API.
• Apply limits to business operations and resource use, not simply to the number of HTTP requests.
• Keep a current inventory of hosts, versions, schemas, owners, environments, and retirement dates for every exposed API.
• Treat data from partner and internal APIs as untrusted input and validate it before storage, rendering, queries, or commands.

How to Use the OWASP API Security Top 10

Use the list to organize design review, code review, automated tests, penetration testing, and operational monitoring. It is a starting taxonomy, not a test plan by itself. Each category needs concrete assets, identities, actions, data, and expected denials from the application under review.

Begin with an API inventory and an authorization model. For each endpoint, identify the allowed caller types, objects, fields, functions, rates, and state transitions. That record becomes the source for negative tests rather than relying on a scanner to guess intended behavior.

The official 2023 methodology also deserves attention. OWASP received no usable data through its public call, so the project team based the edition on specialist review and community feedback. The list is useful, but its ordering is not a prevalence measurement for every organization.

OWASP API Security Top 10 Risks Explained

API1: Broken object level authorization

Broken object level authorization occurs when an API accepts an object identifier but fails to verify that the caller may act on that specific object. Changing /accounts/241 to /accounts/242 may expose another account even though the caller has a valid session.

Centralize object checks close to the data access operation and derive tenant or ownership constraints from the authenticated principal. Test horizontal access between peer users, vertical access across roles, guessed identifiers, bulk endpoints, nested resources, and alternate request methods.

API2: Broken authentication

Broken authentication lets an attacker obtain, reuse, predict, or bypass credentials and sessions. Weak password recovery, missing token validation, accepted tokens for the wrong audience, absent rate limits, and sessions that survive logout all fit this category.

Use a reviewed identity provider where possible, verify issuer, signature, audience, expiry, and intended token type, and protect recovery as carefully as sign-in. Rotate keys safely, revoke compromised sessions, and monitor credential stuffing and automated token abuse.

API3: Broken object property level authorization

Property authorization controls which fields a caller may read or change. The 2023 category combines concerns previously discussed as excessive data exposure and mass assignment because both arise when code exposes properties without a caller-specific decision.

Define explicit response and update schemas for each operation and role. Do not serialize an internal object and hope the client ignores sensitive fields. Reject unknown update properties, protect server-managed fields, and test whether users can read or set ownership, price, role, status, balance, or approval attributes.

API4: Unrestricted resource consumption

An API can consume database connections, memory, CPU, storage, messages, third-party charges, or model tokens even when request volume looks modest. One expensive query, oversized upload, or bulk export can cost more than thousands of cheap requests.

Set limits on payload size, page size, query depth, execution time, concurrency, records returned, file processing, downstream calls, and spending. Enforce the limits at the earliest reliable layer and return controlled errors rather than allowing work to continue after the client disconnects.

API5: Broken function level authorization

Function level authorization fails when a caller reaches an operation reserved for another role or context. An ordinary user may discover an administrative route, change the HTTP method, or call a hidden mobile endpoint that the interface never displays.

Authorize every function on the server using deny-by-default policy. Grouping routes under an admin path may help organization, but the path is not a control. Test role changes, alternate methods, versioned routes, internal endpoints, batch operations, and functions exposed through GraphQL mutations.

API6: Unrestricted access to sensitive business flows

Some API operations are valid individually but harmful when automated at scale. Ticket purchasing, account creation, reservation, coupon redemption, referral, commenting, and password-reset workflows can be abused by bots without exploiting a coding defect.

Identify sensitive flows during design and state the unacceptable automated outcome. Controls may include per-identity limits, device or session signals, proof of possession, queueing, step-up verification, anomaly detection, and business-specific velocity rules. Generic request throttling alone may block legitimate users while missing distributed abuse.

API7: Server-side request forgery

Server-side request forgery occurs when an API fetches a caller-controlled URL without restricting the destination. Webhooks, import functions, link previews, image fetchers, and cloud integrations can become paths to internal services or metadata endpoints.

Allowlist schemes and destinations where the feature permits it, resolve and validate addresses, block private and link-local ranges, restrict redirects, and use an outbound proxy with network policy. Recheck the destination after DNS resolution and each redirect because a safe-looking hostname can resolve somewhere sensitive.

API8: Security misconfiguration

Misconfiguration includes permissive cross-origin rules, verbose errors, debug endpoints, default credentials, unnecessary methods, missing TLS, insecure cloud settings, and inconsistent controls across gateways and application code. APIs often span several layers, so a secure application configuration can still be exposed by its proxy or deployment platform.

Keep configuration in reviewed code, use secure environment baselines, and compare deployed state with that baseline. Remove unused features, standardize error handling, patch components, and test production from an external perspective rather than assuming staging settings carried over.

API9: Improper inventory management

Unknown hosts and old versions evade normal testing and patching. Documentation may describe version three while version one remains reachable on another domain with weaker authentication or a debug route.

Maintain an inventory that connects every hostname, base path, version, environment, schema, data classification, owner, gateway, repository, and retirement state. Discover assets from DNS, gateways, cloud control planes, traffic, certificates, and code, then compare observations with the approved catalog.

API10: Unsafe consumption of APIs

Applications often trust data from partner or internal APIs more than direct user input. If an upstream service is compromised or returns unexpected content, the consuming application may pass it into a query, template, redirect, parser, or command.

Validate upstream responses against a schema and business rules, set timeouts and size limits, and handle errors without unsafe fallbacks. Authenticate the upstream service, protect redirect and callback destinations, and assign the integration no more downstream permission than it needs.

Authorization Tests Need Expected Denials

A positive test proves that one allowed request works. It says little about whether another identity can reach the same object or function. For each endpoint, create a matrix of caller, tenant, role, object owner, field, action, and state, then mark the combinations that must fail.

Run those tests at the API layer rather than only through the user interface. Clients hide endpoints and fields, but attackers can send their own requests. Include missing identifiers, duplicate parameters, alternative content types, batch inputs, GraphQL aliases, and stale sessions.

Authorization also needs lifecycle tests. A permission may be correct when granted and wrong after a role change, tenant transfer, account suspension, or object reassignment. Verify cache invalidation and token behavior after those events.

API Inventory Should Connect Design and Runtime

An OpenAPI document is useful, but it does not prove which versions are deployed or receiving traffic. Combine design records with runtime discovery from gateways, load balancers, DNS, certificates, cloud assets, and logs. Differences between the two views are security findings.

Inventory should support action. An owner needs to know which repository and deployment remove an old endpoint, which customers still use it, and what data it handles. Marking an API as “legacy” without a retirement condition leaves the exposure in place.

Machine-readable schemas also improve testing. They can drive contract checks, input fuzzing, response validation, and detection of undocumented fields. They cannot infer business authorization, so manual rules and purpose-built negative tests remain necessary.

API Top 10 and Web Top 10 Cover Different Questions

The OWASP Web Application Top 10 2025 includes broad application risks such as broken access control, supply chain failures, injection, insecure design, integrity failures, and exceptional-condition handling. The API list focuses more closely on object identifiers, properties, business flows, inventory, resource consumption, and upstream API trust.

Neither list makes the other redundant. A web application backed by APIs can have an API1 object authorization flaw and an A05 injection flaw in the same endpoint. Map both lists to the architecture, then deduplicate controls and tests.

Frequently Asked Questions

What is the latest OWASP API Security Top 10 version?

The current stable edition is the OWASP API Security Top 10 2023. It replaced the first edition published in 2019 and changed several categories. Teams should include the edition year in reports because identifiers and names differ between versions.

What is the difference between API1, API3, and API5?

API1 asks whether the caller may access a particular object. API3 asks which properties of that object the caller may read or change. API5 asks whether the caller may invoke the function at all.

Can an API scanner test the whole Top 10?

A scanner can find exposed endpoints, malformed input handling, configuration problems, and some known vulnerability patterns. It usually cannot infer ownership, role intent, sensitive business flows, or acceptable object transitions without application context. Effective testing combines automation with an authorization model and business-specific negative cases.

Is rate limiting enough for API4 and API6?

Request rate limits help, but API4 also covers expensive operations, payloads, storage, third-party charges, and concurrent work. API6 concerns valid business actions abused at scale, sometimes through many identities and addresses. Controls need to measure the resource or business outcome that the application must protect.