OWASP API Security Top 10 (2023): A Developer's Guide With AI Audit Prompts

APIs are the bloodstream of modern software, and they get attacked differently from web pages. A scanner that looks at rendered HTML sees nothing wrong with an endpoint that cheerfully returns another user's data — because the bug is in the authorization logic, not the output. That's why APIs need their own threat model, and why OWASP maintains a dedicated API Security Top 10, updated in 2023.

This is a developer's walkthrough: what each of the ten risks actually means, how to recognize it in your own code, and a free way to audit your whole API against all ten with an AI agent.

The list

The OWASP API Security Top 10 (2023), in order:

1. API1 — Broken Object Level Authorization (BOLA)
2. API2 — Broken Authentication
3. API3 — Broken Object Property Level Authorization (BOPLA)
4. API4 — Unrestricted Resource Consumption
5. API5 — Broken Function Level Authorization (BFLA)
6. API6 — Unrestricted Access to Sensitive Business Flows
7. API7 — Server-Side Request Forgery (SSRF)
8. API8 — Security Misconfiguration
9. API9 — Improper Inventory Management
10. API10 — Unsafe Consumption of APIs

Let's take them one at a time.

API1 — Broken Object Level Authorization (BOLA)

The #1 API risk since 2019, and by most measures involved in around 40% of API attacks. BOLA is simple: an endpoint accepts an object identifier and returns (or modifies) the object without verifying the caller is allowed to access it.

GET /api/orders/1043   → returns order 1043
GET /api/orders/1044   → returns someone else's order

Spot it in code: any handler that reads an ID from the request and queries by it. The fix is an ownership check on every such query — WHERE id = :id AND owner_id = :currentUser — not just WHERE id = :id.

API2 — Broken Authentication

Weak or missing verification of who is calling. JWTs accepted without signature validation, tokens that never expire, no rate limit on login, guessable password-reset tokens. Kept its #2 spot from 2019.

Spot it in code: token validation that trusts the payload without checking the signature; auth middleware that's applied inconsistently; login endpoints with no brute-force protection. (For the full auth surface, see the authentication audit.)

API3 — Broken Object Property Level Authorization (BOPLA)

New in 2023, consolidating two older risks. It's authorization at the field level, in both directions:

• Mass assignment: the client sends {"isAdmin": true} and your code spreads the whole body into the update.
• Excessive data exposure: the response includes fields the user shouldn't see (password hashes, internal flags, other users' data) because you returned the whole record.

Spot it in code: Object.assign(user, req.body) or { ...req.body } into a database write; serializers that return the raw model instead of an explicit allowlist of fields.

API4 — Unrestricted Resource Consumption

No limits — on request rate, page size, payload size, query complexity, or spend. This is the door to denial-of-service and, on paid infrastructure, denial-of-wallet.

Spot it in code: endpoints with no rate limit; list endpoints with no maximum limit; queries that can be forced unbounded. This is partly a code fix (caps) and partly a runtime problem (see "Beyond code" below).

API5 — Broken Function Level Authorization (BFLA)

Where BOLA is about objects, BFLA is about actions. A regular user can invoke an admin-only function because the role check is missing, wrong, or enforced only in the UI.

Spot it in code: admin routes that check the role client-side but not server-side; a shared handler where the privileged branch isn't gated; /api/admin/* routes missing the admin middleware.

API6 — Unrestricted Access to Sensitive Business Flows

New in 2023 and subtle: the requests are individually valid, but the flow is abused at scale — bots buying all the concert tickets, mass-creating accounts, scraping a catalog, draining an inventory. There's no "malformed request" to block; the abuse is the pattern.

Spot it in code: you mostly can't. This is a business-logic and runtime-detection risk — identify the sensitive flows (checkout, signup, redemption) and instrument them.

API7 — Server-Side Request Forgery (SSRF)

Added as its own category in 2023. Your API fetches a user-supplied URL, and an attacker points it at something internal — another service, or the cloud metadata endpoint at 169.254.169.254, which can hand over IAM credentials.

Spot it in code: any place a request URL, webhook target, or "import from URL" feature is fetched server-side. The fix is a strict host allowlist plus blocking internal/link-local ranges. (See also secrets & cloud IAM for the credential-theft escalation.)

API8 — Security Misconfiguration

The catch-all: debug mode on in production, an open /swagger or GraphQL introspection, wide-open CORS, missing TLS, default credentials, verbose error messages that leak internals.

Spot it in code and config: environment-dependent settings that default to "developer convenience"; CORS set to * with credentials; stack traces returned to clients.

API9 — Improper Inventory Management

You can't secure what you don't know exists. Old API versions still live, shadow endpoints, internal or test APIs accidentally exposed. Attackers love forgotten endpoints — unpatched, unmonitored, and often missing the auth the current version has.

Spot it: this needs discovery, not just code reading — enumerate every route that actually serves traffic and compare it to what you think you run. See API attack surface discovery & mapping.

API10 — Unsafe Consumption of APIs

The mirror of the rest: you trust the third-party APIs you call. If an upstream is compromised or returns malicious data, and you pass it straight into a query, a template, or a redirect, their problem becomes yours.

Spot it in code: responses from external APIs used without validation; following redirects blindly; trusting upstream data as if it were your own.

Audit your API against all ten — free, with an AI agent

Reading this list is step one. Checking your actual code against it is the work. You can hand that work to an AI agent:

npm install securenow

Go to /threat-modeling/api-security and click Copy prompt. Paste it into your AI coding agent (Claude Code, Cursor, Codex) opened at your project root. The prompt walks API1–API10 against your real routes and produces a report of weaknesses with file:line references — plus a companion report of the runtime detections to build. It runs locally; your code is never uploaded; it's free.

If your API includes GraphQL, run the GraphQL security prompt alongside it; for webhooks, the webhooks prompt.

Beyond code: the risks you can't fix in a file

Two of the ten — API4 (Unrestricted Resource Consumption) and API6 (Sensitive Business Flows) — can't be fully solved in source code, because the individual requests are valid. The attack is the volume and the pattern. Those require runtime detection: rules that flag an IP flooding an endpoint, or automation abusing a sensitive flow, and remediation that rate-limits or blocks.

That's the second half of a real API security posture, and it's covered in Part 5 of the AI Security Auditing series and Anatomy of an API abuse campaign.

Summary

The OWASP API Security Top 10 (2023) is the map. BOLA and BFLA (authorization) are where most APIs bleed; API3 covers the field-level gaps; API4 and API6 are runtime problems; API7 (SSRF) is the one that reaches your cloud credentials; and API9 reminds you that your biggest risk might be an endpoint you forgot exists. Audit your code against all ten, back the runtime risks with detections, and re-run it every release.

Audit your API against the OWASP API Top 10 now →