OWASP API Security Top 10 2023: Practical Guide

Use the 2023 edition as a map

The OWASP API Security Top 10 2023 is an awareness list, not a complete test plan or a certification. Its categories help a team ask where an API could expose data, privileges, infrastructure, or business capacity. Start with the actual actors, assets, and routes in your system. A risk becomes actionable when you can name an operation, a misuse case, a control, and a test that would fail if the control disappeared.

The published list contains ten categories: broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption, broken function level authorization, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration, improper inventory management, and unsafe consumption of APIs. It does not contain a separate 2026 edition in this article; use the edition year when citing a category identifier.

API1 and API3: protect objects and properties

API1 concerns whether a caller may access a particular object. A valid token and a documented /orders/{id} path do not prove that order 42 belongs to the caller. Test with two users in different tenants: create an order as one, then request, update, and delete it as the other. Repeat for list filters, nested routes, exports, and background jobs. Deny access consistently without revealing whether a forbidden object exists.

API3 concerns which fields may be read or changed. A request schema that includes role, price, ownerId, or approvalStatus invites review because mass assignment can move privileged state into user input. Use explicit server-side allowlists per operation and role. For output, test that a low-privilege response omits private fields even when a client asks for expanded relations. An OpenAPI schema can reveal suspicious fields, but only live tests prove enforcement.

API2 and API5: distinguish identity from permission

API2 covers broken authentication. Check token signature, issuer, audience, expiry, revocation strategy, and authentication flows appropriate to the client. Test missing, malformed, expired, and wrong-audience credentials. Do not treat possession of any valid bearer token as authority for every service. Review token handling in logs and redirects so credentials do not leak through operational tooling.

API5 covers function-level authorization: whether a role may invoke an action at all. A support user may read a ticket but not approve a refund, and a normal user may not call an admin export route. Build an operation-by-role matrix and run negative tests for each sensitive action. Method changes matter: a protected GET does not imply its PATCH or DELETE neighbour is protected. Document requirements in OpenAPI, then verify middleware and business logic.

API4 and API6: bound cost and business abuse

API4 focuses on resource consumption. Limit page size, upload bytes, query complexity, concurrency, and expensive exports according to measured service capacity. Rate limits alone do not bound a single costly request. Test maximum values, repeated requests, and cancellation or timeout behaviour under controlled load. Check the effect on downstream dependencies, not only the gateway response.

API6 addresses sensitive business flows such as reservations, purchasing, or invitation sending. A bot may abuse a flow while staying within a simple per-IP rate limit. Define what legitimate use looks like, then add account, device, payment, and workflow controls suited to the harm. Test repeated attempts across identities and sessions. Document false-positive handling so a defensive rule does not silently block legitimate customers.

API7 and API8: defend integrations and configuration

API7 is server-side request forgery. Any endpoint that fetches a user-supplied URL, webhook destination, avatar, or document preview needs a strict destination policy. Resolve DNS carefully, reject internal and metadata network ranges, limit redirects, and isolate outbound access. Test redirects and hostname changes in a safe environment. A declared string format in OpenAPI does not stop the server from calling an internal address.

API8 covers security misconfiguration in the stack: permissive CORS, exposed debug paths, weak transport settings, verbose errors, and inconsistent headers are common examples. Compare gateway, app, and cloud configuration across environments. An OpenAPI contract can document the intended policy or reveal missing declarations, but it usually cannot see an ingress rule or production toggle. Verify the deployed system directly.

API9 and API10: know what runs and what you trust

API9 is improper inventory management. Maintain owners, versions, hosts, environments, and retirement dates for every deployed route. Compare gateway and service discovery data with the published OpenAPI set. An undocumented route may be an old service, a deliberately private endpoint, or a stale contract; investigate before declaring a vulnerability. Remove unused versions through a measured deprecation process.

API10 is unsafe consumption of APIs. Treat partner responses as untrusted input: validate types and bounds, set timeouts, constrain redirects, authenticate upstream services, and fail safely when data is malformed. Review how webhook signatures are checked and how third-party errors are mapped to your own responses. An integration can make your API vulnerable without the attacker ever calling your endpoint directly.

Turn the list into a repeatable review

For each exposed operation, record relevant categories, evidence, control owner, and one positive and one negative test. Use a contract scan early to find missing design declarations, then exercise authorization, routing, quotas, and integrations in a test environment. Keep a trace from the risk to the test so a future refactor does not remove the protection unnoticed.

Prioritise by the sensitivity of data and business function, the exposure of the route, and the plausible attack path. A low-cost public list and a privileged funds-transfer action need different depth of review. Revisit the matrix after a new endpoint, external provider, or client appears. The Top 10 gives useful prompts; the service's threat model decides what matters most.

Worked example: an invoice export

Consider GET /accounts/{accountId}/invoice-export. API1 asks whether the account belongs to the caller. API3 asks whether the export contains fields the caller may see. API4 asks whether the export is bounded in size and concurrency. API5 asks whether this role may start an export at all. API6 asks whether repeated exports can be abused to obtain value or exhaust a shared resource. These are different questions about one operation.

Write tests accordingly. Create two tenants and request the first tenant's export with the second tenant's token. Try a lower-privilege role from the right tenant. Inspect the generated file for fields beyond the role's scope. Run a controlled sequence of export requests and verify a documented quota or job limit. Inspect logs for tokens and invoice data. A static OpenAPI review can highlight missing security, errors, or limits, but it cannot observe these outcomes.

What a contract scan can and cannot map

An OpenAPI scanner can point to operations lacking authentication declarations, weakly constrained request bodies, missing error responses, and unbounded collection design. Those signals overlap several OWASP themes, especially misconfiguration and resource consumption. They are not a one-to-one certification for all ten categories. A missing declaration might be a documentation defect; a present declaration might not be enforced. Both cases need follow-up.

For BOLA, function authorization, sensitive business flows, SSRF, and unsafe partner consumption, the decisive evidence often lives in service code, infrastructure, and live behaviour. Choose a test technique appropriate to each risk. A cross-tenant request probes BOLA; an isolated fetcher test probes SSRF; a malformed partner response probes unsafe consumption. Document the result and the owner so the category label is tied to a real control.

Avoid common interpretation errors

Do not assume that “injection” has a numbered API category of its own in the 2023 list. Injection and other weaknesses can contribute to listed risks and remain important even when their name is absent from the ten headings. Similarly, a 429 response alone does not resolve every resource-consumption or business-flow problem. The implementation must impose a meaningful bound, and the bound must fit the work.

Use edition identifiers exactly when writing tickets and reports. API3:2023 differs from its earlier formulation because property-level authorization covers both excessive exposure and unsafe writable fields. A link to the official risk page helps reviewers understand the intended category. Avoid trend claims or prevalence percentages unless a source and measurement method are available; the list is a guide for awareness and prioritisation, not a measurement of your service.

Build a compact review worksheet

For each sensitive operation, write a row with actor, object, action, data returned, cost, external dependency, and deployed host. Add columns for relevant OWASP categories, expected control, negative test, and owner. Start with the handful of routes that move money, expose personal data, or change privileges. This keeps the review practical and makes gaps visible.

Update the worksheet when a new version, role, partner, or background job appears. Retest the same flow after a gateway or identity-provider migration, because a correct application check can be bypassed by an alternate route. Close a finding only after the owner records the changed behaviour or a scoped acceptance. This turns an awareness list into a living security practice.

Continue the work

Use these guides to put the checks into your API review process:

• What API SAST can see in the OWASP risks
• Choose API security testing methods
• Review an OpenAPI contract

Primary reference: OWASP API Security Top 10 2023.

APISAST reviews OpenAPI and Swagger contracts for documented design signals. Confirm authorization, enforcement, performance, and abuse controls against a running service.