The OWASP API Security Project published its current API Security Top 10 in 2023, replacing the 2019 edition with a list reordered around how APIs actually fail in production rather than how web apps fail in general. This API-specific list — often searched for as the API OWASP Top 10 or the OWASP API Top Ten — is a sibling to the better-known OWASP Top 10 for web applications, scoped specifically to the failure modes APIs expose directly. The new #1 risk, Broken Object Level Authorization, sounds abstract until you translate it into a request: change /api/orders/1002 to /api/orders/1003 and see if someone else's order comes back. No fuzzing framework, no exploit chain — just an ID a client controls and a server that never rechecks ownership. That single pattern, and nine others like it, account for a disproportionate share of API breaches disclosed over the past several years, because APIs expose their internal data model far more directly than a rendered web page ever did. GraphQL makes this worse in one specific way: a single /graphql endpoint can expose the entire schema through introspection, turning what used to be dozens of separate REST routes to enumerate into one query. This post walks through all ten 2023 categories — API1 through API10 — with a concrete test for each and the mitigation that actually closes it, not just a WAF rule that masks the symptom.
What is Broken Object Level Authorization and how do you test for it?
API1:2023 – Broken Object Level Authorization (BOLA) happens when an API endpoint accepts an object ID from the client and returns or modifies that object without verifying the requesting user actually owns or is permitted to access it. It is OWASP's #1 API risk in the 2023 edition, and it's also the easiest to test manually: authenticate as User A, capture a request like GET /api/invoices/{id}, then replay it with User B's session token and A's invoice ID. If the response returns A's data, the endpoint is broken. Test every ID-bearing path this way, including nested resources ( /api/orgs/{orgId}/users/{userId} ) where the outer ID might be checked but the inner one isn't. The fix is to enforce object-level authorization server-side on every single access to a data object, using the caller's identity from the session — never trust an ID's presence in the URL or body as implicit permission, and prefer non-sequential, unguessable identifiers (UUIDs) so IDs can't be enumerated even if a check is later missed.
How is Broken Authentication different from a weak password policy?
API2:2023 – Broken Authentication covers the mechanisms that verify identity — token issuance, password reset, credential stuffing resistance — not just password strength rules. Common failures include APIs that accept API keys with no expiry, JWTs signed with a weak or guessable secret, password-reset endpoints with no rate limit, and mobile-app APIs that ship a hardcoded secret in the client binary. To test, pull apart the app's traffic and check whether the JWT's alg header can be switched to none or a weak HMAC secret can be brute-forced, whether login endpoints lock out after repeated failures, and whether tokens are revoked on logout or password change. Mitigation means treating authentication as its own hardened subsystem: short-lived access tokens with refresh rotation, rate limiting and account lockout on every credential-based endpoint, and multi-factor authentication for sensitive operations — not just the initial login. Credential stuffing against API endpoints specifically (rather than the web login form) remains a common path in because many teams harden the UI login flow and forget the API accepts the same credentials directly.
What's the difference between Object Level and Object Property Level authorization?
API3:2023 – Broken Object Property Level Authorization is what BOLA becomes once you're inside the right object: even with correct access to a resource, an API can leak or allow modification of individual fields the caller shouldn't see or change. The classic case is excessive data exposure — a /api/users/{id} endpoint that returns the full user record, including a role or isAdmin field, because the backend serializes the whole database object rather than a defined response schema. The inverse failure, mass assignment, is when a PATCH /api/users/{id} endpoint blindly binds the request body to the user model, so a client can include "role": "admin" in the payload and the server writes it. Test by diffing every field in a response against what the UI actually displays, and by submitting extra, unexpected fields on write requests to see if they get persisted. Fix both directions with explicit allow-lists: define per-endpoint response and request schemas, and reject or strip any field not on the list rather than trusting an ORM's default serialization.
Why do rate limits alone not stop Unrestricted Resource Consumption?
API4:2023 – Unrestricted Resource Consumption covers any request an API accepts without bounding the compute, memory, storage, or downstream cost it triggers — and a basic requests-per-minute rate limit only catches the volume dimension, not the cost-per-request dimension. A GraphQL API is the sharpest example: a single query can nest nine levels deep, joining across relationships, and generate thousands of database calls behind one HTTP request that a per-IP rate limiter counts as exactly one hit. REST APIs have their own version — an unbounded ?limit= query parameter, or a bulk-export endpoint with no cap on the array size in the request body. Test by sending pagination parameters with very large values, deeply nested GraphQL queries, and batch operations sized well beyond normal use, then watch response latency and backend resource usage. Mitigations include enforcing query complexity/depth limits and cost analysis specifically for GraphQL (rejecting a query above a computed cost score before execution), hard server-side caps on pagination and payload size regardless of client-supplied values, and timeouts on every downstream call the API makes.
How do Broken Function Level Authorization and Sensitive Business Flow abuse differ?
API5:2023 – Broken Function Level Authorization is a horizontal-to-vertical escalation problem: an endpoint intended for admins is reachable by a regular authenticated user because the server checks that a session exists, but not what role it holds. Test this by taking every admin-only route documented in the API spec and calling it with a standard user's token — a DELETE /api/admin/users/{id} that succeeds for a non-admin session is a direct hit. API6:2023 – Unrestricted Access to Sensitive Business Flows is a different, newer category in the 2023 list: it targets flows that are individually authorized correctly but can be abused at scale, like a ticket-purchase or coupon-redemption endpoint hit thousands of times per second by bots to exhaust inventory or a promo budget. Mitigating API5 means enforcing role checks centrally (middleware or a policy engine, not scattered per-route conditionals) so no new endpoint ships without one. Mitigating API6 requires business-logic-aware controls — device fingerprinting, CAPTCHA on high-value flows, and anomaly-based throttling — because rate limits alone don't distinguish a real customer from a scripted one.
What makes SSRF and misconfiguration such persistent API risks?
API7:2023 – Server Side Request Forgery arises whenever an API fetches a resource based on a client-supplied URL — a webhook target, an image-import-by-URL feature, an OAuth callback validator — without restricting what that URL can point to, letting an attacker redirect the server's own request to internal infrastructure like a cloud metadata endpoint. Test by supplying internal IP ranges, localhost, and cloud metadata addresses ( 169.254.169.254 ) as the target URL and observing whether the server connects. SSRF also holds a slot (A10:2021) in the general OWASP Top 10, which says something about how persistent the pattern is across both web apps and APIs. API8:2023 – Security Misconfiguration is broader and often the easiest to find at scale: verbose error messages leaking stack traces, permissive CORS headers set to * on authenticated endpoints, missing security headers, and default credentials left on management interfaces. Both categories benefit from dynamic testing against a running instance rather than code review alone, since misconfiguration frequently lives in deployment and infrastructure, not source. Safeguard's DAST engine runs exactly this class of check — safe, non-destructive requests against a verified, in-scope target to flag missing headers and misconfiguration classes — under mandatory rate limits and an audit trail, which is the practical way to catch API8-style drift between what code review approved and what's actually deployed.
Why do Inventory Management and third-party API consumption make the list?
API9:2023 – Improper Inventory Management reflects a simple reality: you can't secure an API endpoint you don't know exists. Shadow APIs (old versions left running after a "v2" ships), undocumented internal endpoints exposed by accident through a shared gateway, and staging environments reachable from the internet are all inventory failures, not logic bugs. Test by comparing your API gateway's actual traffic logs against your published OpenAPI or GraphQL schema — anything hit in production that isn't documented is a gap. API10:2023 – Unsafe Consumption of APIs flips the direction: it's about the risk your own API takes on by trusting data or redirects from third-party APIs it calls, without the same input validation you'd apply to a request from your own frontend. Mitigating API9 means maintaining an automated, continuously updated inventory tied to actual deployed endpoints, not a manually edited wiki page. Mitigating API10 means treating every third-party API response — even from a paid, trusted vendor — as untrusted input requiring the same validation and sanitization applied to any external data.
How does Safeguard help?
Testing all ten categories by hand across every endpoint doesn't scale, which is why the two Safeguard capabilities that map most directly onto this list are SAST and DAST working together. SAST traces source-to-sink dataflow through Python, JavaScript/TypeScript, and Java codebases (with more languages planned), which is directly useful for spotting the code-level patterns behind BOLA and BFLA — a route handler that reads an object ID from the request and passes it straight into a query without an ownership check shows up as a taint path a reviewer can inspect. DAST tests the running API itself with safe, non-destructive requests against a verified, in-scope target — appropriate for surfacing API8-style misconfiguration and injection-class issues in a live deployment, gated by mandatory rate limits, scope allow-lists, and a full audit trail. Neither engine claims to close all ten OWASP API risks on its own — business-logic categories like API6 still require human threat modeling — but pairing dataflow-aware static analysis with authorized dynamic testing against your actual deployed API closes a meaningful part of the gap between what a schema says an endpoint does and what it actually allows.
Frequently Asked Questions
What is the OWASP API Top 10 (also called the API OWASP Top 10 or Top 10 OWASP list)? It's OWASP's ranked list of the ten most common ways APIs fail in production — from broken object-level authorization down to unsafe consumption of third-party APIs — maintained separately from, but alongside, the general OWASP Top 10 for web applications. The current version is the 2023 edition covered throughout this post.
How does the OWASP Top 10 for API differ from the general OWASP Top 10? The general OWASP Top 10 covers web application risks broadly (things like injection and security misconfiguration across any web app), while the OWASP Top 10 for API is scoped specifically to how APIs expose their data model directly — object-level and function-level authorization, excessive data exposure, and resource consumption are weighted differently because an API has no rendered UI standing between a client and the underlying object.
Is there an OWASP Top 10 2024 update? No. OWASP did not publish a new API Security Top 10 or general Top 10 dated 2024 — the 2023 edition covered in this post remains the current one. Searches for "OWASP Top 10 2024" are typically looking for the latest guidance, which as of this writing is still the 2023 list for both the API-specific and general tracks.
What changed between the OWASP 2019 API Top 10 and the 2023 edition? The 2019 list was OWASP's first dedicated API Security Top 10. The 2023 revision reordered and relabeled several categories to better match real-world incident data — for example, Broken Object Level Authorization stayed at #1, while newer categories like Unrestricted Access to Sensitive Business Flows (API6:2023) and Unsafe Consumption of APIs (API10:2023) were added to reflect failure modes that weren't broken out separately in 2019.
Is OWASP ESAPI relevant to API security? Not directly to this list. OWASP ESAPI (the Enterprise Security API) is a legacy Java library focused on input validation, output encoding, and session-management helpers for traditional web applications — it predates the API-specific Top 10 and addresses a different layer of the problem than authorization, rate limiting, or inventory management. Teams securing modern REST or GraphQL APIs generally rely on framework-native validation and the mitigations described above rather than adopting ESAPI directly.