The OWASP API Security Top 10 (2023), Category by Category

The OWASP API Security Top 10 is the industry's shared list of the most common, most damaging ways APIs get breached. It is separate from the better-known OWASP Web Top 10 because APIs fail differently: there is no browser, no user clicking through a UI, just a programmatic endpoint that an attacker can probe and automate. The 2023 edition is the reference auditors, pentesters, and engineers all use, so knowing it by number (API1, API2, …) is part of speaking the language. This lesson walks all ten categories with a concrete example of each and — the throughline — the evidence that proves the category is mitigated. Notice how many of them are authorization failures: that is not an accident.

API1:2023 — Broken Object Level Authorization (BOLA)

The single most common and most damaging API flaw. The endpoint authenticates the caller but never checks whether this caller owns that object. GET /api/invoices/9001 returns invoice 9001 to anyone logged in — so an attacker changes 9001 to 9002 and reads someone else's invoice. Incrementing an ID in a loop dumps the whole table.

Fix: on every request, verify the authenticated user is authorized for the specific object id (an ownership or relationship check), not just that they are logged in.
Evidence: code/policy showing per-object authorization, and tests proving a request for another user's object id returns 403/404.

Changing ?id=124 to ?id=125 and getting someone else's invoice

API2:2023 — Broken Authentication

The authentication itself is weak or bypassable: no rate limit on login (credential stuffing), JWTs accepted with alg: none or an unverified signature, tokens that never expire, password reset that leaks whether an account exists, or API keys in URLs.

Fix: strong authentication — verified token signatures, short expiry, rate-limited and monitored login, no credentials in URLs.
Evidence: token policy, login rate-limit config, and proof the verifier rejects unsigned/none tokens.

API3:2023 — Broken Object Property Level Authorization (BOPLA)

Authorization is checked at the object level but not at the property level. Two failure modes: excessive data exposure (the API returns the full user object including password_hash, ssn, is_admin, trusting the client to hide them) and mass assignment (the API blindly binds the request body to the model, so a user sends {"is_admin": true} on a profile update and escalates).

Fix: return and accept only an explicit allow-list of properties per role; never auto-bind the whole request body.
Evidence: response schemas/serializers showing field-level filtering; tests proving a privileged field cannot be set by an unprivileged caller.

Adding is_admin: true to the profile-update request body

API4:2023 — Unrestricted Resource Consumption

The API has no limits, so a caller can exhaust resources or run up cost: no rate limit, no pagination cap (?limit=10000000), no payload size limit, expensive operations with no throttle. This is how APIs get DoS'd — and, in the cloud, how an attacker runs up your bill.

Fix: rate limits, pagination/response-size caps, payload limits, timeouts, and spend alerts.
Evidence: gateway rate-limit and quota config, and alerting thresholds.

Opening the cloud bill after someone found ?limit=10000000

API5:2023 — Broken Function Level Authorization (BFLA)

Where BOLA is about data objects, BFLA is about operations. A regular user calls an admin-only function — DELETE /api/users/42 or POST /api/admin/refund — because the endpoint checks that you are authenticated but not that you hold the admin role. Often the admin endpoints are simply undocumented and assumed hidden.

Fix: enforce role/function authorization on every endpoint, deny by default, and don't rely on obscurity.
Evidence: the endpoint-to-role authorization matrix and tests proving non-admins get 403 on admin functions.

'The admin endpoint is fine — it's not in the docs'

API6:2023 — Unrestricted Access to Sensitive Business Flows

The individual endpoints are secured, but a business flow can be automated for harm: a bot buys all the concert tickets to scalp them, mass-creates fake accounts, or scrapes the entire product catalog. No single request is "unauthorized" — the abuse is in the volume and intent.

Fix: identify sensitive flows and add anti-automation (device fingerprinting, CAPTCHA, velocity limits, behavioral detection).
Evidence: documented sensitive-flow inventory and the anti-automation controls applied to each.

API7:2023 — Server Side Request Forgery (SSRF)

The API fetches a URL the caller supplies — for a webhook, an image import, a link preview — without validating it. The attacker points it at internal addresses (http://169.254.169.254/ for cloud metadata, or internal services) and the server fetches them, leaking credentials or reaching systems the attacker cannot.

Fix: validate and allow-list outbound URLs, block private/link-local ranges, disable redirects to internal hosts.
Evidence: the URL allow-list/validation logic and tests proving requests to internal ranges are blocked.

API8:2023 — Security Misconfiguration

The catch-all: verbose error messages leaking stack traces, missing security headers, permissive CORS (Access-Control-Allow-Origin: * on an authenticated API), default credentials, unpatched components, debug endpoints left enabled in production.

Fix: harden by default, lock down CORS, strip error detail in production, patch, and remove debug surface.
Evidence: hardening baseline/config-as-code, CORS policy, and patch status.

API9:2023 — Improper Inventory Management

You can't secure what you don't know you're running. Old /v1/ endpoints still live after /v3/ shipped, a forgotten staging API exposes production data, undocumented "shadow" APIs sit unmonitored. Attackers find the deprecated, unpatched version you forgot about.

Fix: maintain an inventory of every API, version, and environment; retire deprecated versions; document and monitor all of them.
Evidence: the API inventory (versions, environments, owners, status) and proof deprecated versions are decommissioned.

API10:2023 — Unsafe Consumption of APIs

Your API trusts data from third-party APIs it calls. You validate user input rigorously but blindly trust a partner's response, follow its redirects, or pass its data into a query unescaped. A compromised or malicious upstream then becomes your vulnerability.

Fix: treat third-party responses as untrusted input — validate, set timeouts, don't blindly follow redirects.
Evidence: input validation on upstream responses and the third-party integration review.

ID     CATEGORY                              TYPICAL FINDING                         EVIDENCE OF MITIGATION
-----  ------------------------------------  --------------------------------------  ----------------------------------
API1   Broken Object Level Auth (BOLA)       change /invoices/9001 -> /9002          per-object authZ + 403 test
API2   Broken Authentication                 JWT alg:none accepted; no login limit   token policy + rate-limit config
API3   Broken Object Property Level (BOPLA)  returns ssn; accepts {"is_admin":true}  field allow-list + serializer
API4   Unrestricted Resource Consumption     ?limit=10000000; no rate limit          gateway quota + spend alerts
API5   Broken Function Level Auth (BFLA)     user calls DELETE /admin/users/42       endpoint-role matrix + 403 test
API6   Sensitive Business Flow Abuse         bot buys all tickets / mass signups     flow inventory + anti-automation
API7   Server Side Request Forgery (SSRF)    webhook URL -> 169.254.169.254          URL allow-list + internal-range test
API8   Security Misconfiguration             CORS *; stack traces; debug endpoint    hardening baseline + CORS policy
API9   Improper Inventory Management         forgotten /v1 on prod data              API inventory + decommission proof
API10  Unsafe Consumption of APIs            trusts partner response blindly         upstream validation + integration review

The OWASP API Top 10 (2023) — category, a typical finding, and the evidence that proves it's mitigated

The pattern an auditor sees

Five of the ten (API1, API3, API5 directly; API6 and API2 partly) are authorization or access failures. The lesson from the previous module holds: authentication is the easy half. The damage comes from APIs that know who you are but never check what you're allowed to reach — per object (BOLA), per property (BOPLA), and per function (BFLA).

The GRC throughline

The OWASP API Top 10 is useful to a GRC Engineer precisely because it converts "is the API secure?" into ten specific, testable questions, each with a concrete piece of evidence. A control framework says "implement logical access controls"; the Top 10 tells you the exact ways that control fails and what to show to prove it doesn't. In the next exercise you will read a mock API spec, find the seeded flaws, and name the Top 10 category for each — exactly what a reviewer does on a real API security assessment.