The OWASP API Security Top 10 is the consensus list of the ten most critical risks specific to APIs. This hub explains every category in the 2023 edition in plain terms, with a short note on how Planck Operator tests for each one against every operation in your API.
The OWASP API Security Top 10 exists because APIs fail differently from web applications. The general OWASP Top 10 centers on injection and client-side flaws, but the risks that actually breach APIs are dominated by authorization: which identity is allowed to reach which object and which function. The 2023 edition captures that reality, and it is the backbone of any serious API penetration testing program. Below is every category, defined plainly, with how the agent tests it.
The API authenticates the caller but does not verify that the object referenced belongs to them, so one account or tenant can read or modify another's data. Consistently the most damaging API flaw.
How Operator tests it: replays one identity requests as another across every object-scoped operation and proves cross-account access. See BOLA testing.
Weak or misimplemented authentication: guessable credentials, flawed token issuance and validation, algorithm confusion, missing expiry, and broken password or key recovery flows that let an attacker assume another identity.
How Operator tests it: exercises token issuance, signature and audience validation, expiry handling, and credential and reset flows as attack surfaces in their own right.
Access control on an object is not access control on its fields. Combines mass assignment, writing properties the server should own, and excessive data exposure, reading properties the API should filter out.
How Operator tests it: injects extra properties into writes and inspects responses for over-returned fields, testing read and write control per property.
Missing limits on what a single caller can make the API spend: unbounded pagination, expensive queries, oversized payloads, and absent rate limits on login, OTP, and enumeration-prone endpoints.
How Operator tests it: measures cost per request and probes rate ceilings in a throttled, coordinated way that records the threshold without causing an outage.
The API does not enforce role checks at the function level, so a lower-privileged user can invoke administrative or privileged operations by calling them directly, guessing routes, or swapping HTTP methods.
How Operator tests it: sends privileged-function requests from lower-privileged roles and confirms the action succeeds. See BFLA testing.
A business flow such as purchasing, booking, or posting is technically authorized but exposed to automated abuse, letting an attacker exhaust inventory, scalp, or spam at machine scale.
How Operator tests it: models the sensitive flows in scope and checks whether they can be driven at automated volume without the controls a legitimate user would face.
The API fetches a remote resource from a client-supplied URL without validating it, letting an attacker reach internal services, cloud metadata endpoints, and other systems the server can see.
How Operator tests it: supplies crafted URLs to every parameter that triggers a server-side fetch and checks for reachability of internal and metadata targets.
Insecure defaults, missing hardening, verbose errors, permissive CORS, unpatched components, and debug features left enabled, each expanding what an attacker can learn or do.
How Operator tests it: fingerprints the stack, inspects headers, CORS, and error behavior, and flags exposed debug and administrative surfaces.
Shadow endpoints that never made the docs and zombie versions that never got retired stay reachable long after teams forget them, often without the controls of the current API.
How Operator tests it: rebuilds the API inventory each run, enumerating old versions, debug and internal routes, then tests what it finds at full depth.
The API trusts data from third-party and upstream APIs too readily, forwarding, deserializing, or acting on it without validation, so a compromised or malicious upstream becomes an attack path.
How Operator tests it: examines how the API handles upstream responses and whether unvalidated third-party data can influence its behavior or data.
The Top 10 captures the most common and impactful classes, and Planck Operator tests every one of them against every operation in your API, not a sampled subset. But real engagements also surface business-logic flaws and chained issues that no list names, which is where reasoning about your specific API matters most.
Authorization runs through the whole list. API1 and API5 sit at the top because proving them requires comparing what different identities can reach, which fixed scanners cannot model. That comparison is the core of how the agent works.
It is a consensus list, maintained by the OWASP API Security Project, of the ten most critical security risks specific to APIs. The current edition is 2023. Unlike the general OWASP Top 10 for web applications, it focuses on the failures unique to APIs, especially authorization flaws such as BOLA and BFLA that dominate real API breaches.
The 2023 edition adds Broken Object Property Level Authorization, which merges the old mass assignment and excessive data exposure categories, and introduces Unrestricted Access to Sensitive Business Flows and Unsafe Consumption of APIs. It also reframes several categories, for example broadening the old lack of resources and rate limiting into Unrestricted Resource Consumption.
The Top 10 is a floor, not a ceiling. It captures the most common and impactful classes, but real engagements also find business-logic flaws and chained issues that no list enumerates. Planck Operator tests every category on the list against every operation and keeps going into logic and abuse cases the list does not name.
Authorization failures dominate. API1 Broken Object Level Authorization is consistently the most damaging and most common, with API5 Broken Function Level Authorization close behind. Both require reasoning about which identity should reach which object or function, which is exactly what automated scanners cannot model, so they are central to how we test.
Give us a seed and one token per role, and the agent will test every category against every operation, then hand you exploit-proven findings. Start with BOLA testing and BFLA testing.