Unrestricted Access to Sensitive Business Flows
OWASP API Security Top 10 · API6:2023
Some abuse involves no technical vulnerability at all: the API works exactly as designed, but automation lets one actor use a business flow at a scale the business never anticipated. Ticket purchasing, inventory reservation, promotional codes, and account creation are all technically valid operations that cause real harm when performed thousands of times by a script.
How it shows up in the real world
- Bots buying limited-stock items the moment they are released, denying access to genuine customers.
- Automated creation of large numbers of accounts to farm signup incentives.
- Scripted enumeration of promotional or gift-card codes.
- Repeatedly reserving inventory without completing purchase to deny availability.
How to mitigate it
- Identify the flows whose abuse would cause business harm and treat scale itself as a threat during design.
- Apply per-identity and per-device throttling, step-up challenges, and human-verification on those flows specifically.
- Detect automation through behavioural and device signals rather than IP reputation alone.
- Add business-side guards such as purchase limits, holding periods, and reservation expiry.
Practice this topic
Test your knowledge of Unrestricted Access to Sensitive Business Flows with exam-style practice questions.
Rest of the API 2023 list
API1:2023Broken Object Level Authorization
The most common and most damaging API flaw. Endpoints take an object identifier from the caller and act on that object without confirming the caller is entitled to it. Because APIs expose identifiers as a matter of design, the entire dataset is often reachable by iterating a value, and the requests look completely legitimate in logs.
API2:2023Broken Authentication
Authentication mechanisms in APIs are often implemented per service and per endpoint, which is exactly the condition in which inconsistencies appear. Token validation may be incomplete, credential endpoints may be unthrottled, and machine-to-machine keys tend to be long-lived, broadly scoped, and rarely rotated.
API3:2023Broken Object Property Level Authorization
Even when access to an object is correct, access to individual fields may not be. This covers both directions: returning properties the caller should not see, and accepting properties the caller should not be able to set. It merges what earlier editions treated separately as excessive data exposure and mass assignment.
API4:2023Unrestricted Resource Consumption
Every API request consumes CPU, memory, storage, bandwidth, and often paid third-party calls. Without limits, a caller can degrade availability or run up costs simply by asking for a great deal, and the requests need not be malformed. Expensive operations such as search, export, report generation, and anything that fans out to other services are the usual pressure points.
API5:2023Broken Function Level Authorization
Where API1 is about which records a caller may touch, this is about which operations they may invoke. Administrative and privileged functions are frequently protected only by being undocumented or absent from the client, so a caller who guesses or observes the route reaches them. Changing an HTTP method on a known path is often enough.
API7:2023Server Side Request Forgery
When an API accepts a URL and fetches it, the caller gains partial use of the server's network position. That position is usually far more privileged than the caller's own: internal services, cloud metadata endpoints, and administrative interfaces are reachable from inside. Features like webhooks, link previews, file import from URL, and PDF rendering are the usual entry points.
API8:2023Security Misconfiguration
APIs inherit misconfiguration risk from the whole stack they run on — gateway, framework, container, orchestrator, and cloud platform — and add some of their own, such as permissive cross-origin policies, verbose error output, and unnecessary HTTP methods left enabled. The gateway is a particular concern because a single permissive rule there applies to every service behind it.
API9:2023Improper Inventory Management
You cannot protect what you do not know you are running. Organisations accumulate old API versions, staging deployments, forgotten integrations, and undocumented internal services, all of which stay reachable and stop receiving patches and review. Old versions are especially dangerous because they often predate the fixes and controls applied to the current one.
API10:2023Unsafe Consumption of APIs
Developers apply scepticism to user input and then extend implicit trust to responses from partner and third-party APIs. That trust is misplaced: an upstream service can be compromised, can be redirected, or can simply return something unexpected. Data arriving from another API deserves the same validation as data arriving from a browser.