Unrestricted Access to Sensitive Business Flows

The newest category on the API list describes an attack where nothing is technically broken. Every request is valid, authenticated, and authorised. The harm comes from running a legitimate business flow — buying, signing up, commenting, reserving — far faster and more often than a human ever could. Unrestricted Access to Sensitive Business Flows is a business-logic risk, and it is invisible to controls that only inspect individual requests.

A sensitive business flow is any sequence of API calls whose automation causes real-world harm to the business or its users. The purchase flow that lets scalpers buy out limited stock in seconds. The signup flow that lets one actor farm thousands of accounts to claim referral credit. The comment flow weaponised for spam, or the search flow used to scrape an entire catalogue and undercut it. None of these requests is malformed; the abuse is the volume and intent behind them.

Why the usual defences miss it

Authentication passes — the accounts are real. Authorization passes — users are allowed to buy and sign up. Input validation passes — the payloads are well-formed. Even a basic rate limit can be defeated by spreading requests across many accounts and IPs. The flaw lives above the request layer, in whether the business flow can be executed at a scale that defeats its purpose. That is why API6 asks a different question: not "is this request valid?" but "should this flow be automatable at all, and by whom?"

Designing flows that resist automation

The first step is not technical: identify which flows are sensitive — those whose mass execution would damage revenue, inventory, reputation, or fairness. You cannot protect a flow you haven't recognised as valuable to an attacker. Then raise the cost of automating it without punishing genuine users.

• Inventory your sensitive flows. List the sequences — purchase, signup, reservation, referral, review — where automation at scale causes harm, and treat those as a protected class.
• Detect non-human patterns. Look at timing, device fingerprints, and behavioural signals to distinguish a person from a script, rather than judging each request in isolation.
• Add friction where it counts. Proof-of-work, step-up challenges, or CAPTCHAs on the sensitive flow specifically raise the attacker's cost while leaving ordinary use mostly untouched.
• Limit by identity and resource, not just IP. Cap purchases per customer, signups per device, and actions per account over meaningful windows — IP-based limits alone are trivially spread across a botnet.
• Enforce business rules server-side. One-per-customer, cooldown periods, and inventory holds must be enforced in the API, never assumed from client behaviour.

API6 is where security and product thinking merge: defending it means understanding what your API is for and how that purpose can be turned against you. The defences are never one-size-fits-all, because the sensitive flows differ for every business. What is constant is the prerequisite — you have to know which flows exist and which ones matter before you can decide how fast a stranger should be allowed to run them.