Unrestricted Access to Sensitive Business Flows happens when an API exposes a flow such as buying, booking, signing up or posting, and nothing stops a script from running that flow at a scale or speed that harms the business. Every request may be valid, authenticated and authorised, which is why scanners rarely find it and why OWASP added it as a new category in the API Security Top 10 2023. This guide goes deeper than the overview in the Top 10 API Security Risks. It explains how to identify which flows are sensitive, how to choose layered controls, how to key limits to identities rather than IP addresses, how to test and measure the result, and how API6 maps to ASVS 5.0, the OWASP Automated Threats handbook and NIST. It is written for product owners, API developers, fraud and trust teams, and application security engineers.
Key takeaways
- API6 is a design flaw, not a coding bug. The endpoint works as written; the failure is that nobody decided how much automated use of the flow the business can tolerate.
- Start with the business, then engineering. OWASP splits mitigation into two layers: identify the flows that hurt the business if overused, then choose the protection that fits each one.
- Limit by business object, not only by request. Units per account, bookings per payment card, referrals per device and sign-ups per email domain stop abuse that request-rate limits never see.
- Machine-to-machine APIs are the soft target. OWASP warns that developer and B2B APIs often lack the protections on the web front end, so attackers go there first.
- Raise attacker cost, do not chase perfection. Device fingerprinting, human detection and timing analysis each slow automation; combined with object limits and monitoring they make abuse uneconomic.
What it is and who it applies to
OWASP's official entry is API6:2023 Unrestricted Access to Sensitive Business Flows. Its risk rating is: exploitability Easy, prevalence Widespread, detectability Average, technical impact Moderate. OWASP states that technical impact is generally not expected; the harm is to the business, for example preventing legitimate customers from buying a product or inflating the internal economy of a game.
OWASP describes the attacker's method as understanding the business model, finding the sensitive flow, working out which endpoints make it up, and automating access. Its prevalence comes from "lack of a holistic view of the API": each endpoint is reviewed on its own and nobody looks at the flow end to end. OWASP's three illustrations:
- Scalping: a script distributed across many IP addresses buys most of a limited gaming console release on launch day for resale.
- Inventory manipulation: a user books 90% of the seats on a flight with no cancellation fee, cancels them days before departure to force price cuts, then buys one cheap seat.
- Referral abuse: a script automates registration so each fake user credits the attacker's wallet in a ride-sharing referral scheme.
OWASP is explicit that sensitivity depends on the business: automated posting is spam to one social network and a welcome integration to another. An endpoint is vulnerable when it exposes a sensitive flow without appropriately restricting access to it. API6 applies to retail, ticketing, travel, gaming, fintech, marketplaces, social platforms and any service with promotions, free tiers or scarce inventory. It also applies to public registries and developer platforms: in the GemStuffer RubyGems campaign, AI agents mass-created accounts with disposable email addresses and sign-up traffic was not rate limited, until the registry closed registration and reopened it with verified, non-disposable email and sign-up rate limits.
API6 differs from API4, which is about the cost of operations to the provider, and from API2, which covers authentication brute force. Credential stuffing touches all three; the login flow is a sensitive business flow too.
Structure and key requirements
OWASP's How To Prevent section has two layers, and the engineering layer lists four mechanisms that slow automated threats, plus one architectural rule.
Layer 1: identify the sensitive flows
Map each flow to the abuse it invites. The OWASP Automated Threats to Web Applications project gives a shared vocabulary (OAT identifiers) that fraud, product and security teams can all use.
| Business flow | Abuse at scale | OWASP Automated Threat | Object-level limit that helps |
|---|---|---|---|
| Purchase of limited stock | Bulk buying for resale | OAT-005 Scalping | Units per account, per card, per delivery address |
| Add to cart, reservation, seat hold | Holding stock without paying | OAT-021 Denial of Inventory | Hold expiry, holds per account, deposit or fee |
| Last-minute bid or offer | Automated action at the final moment | OAT-013 Sniping | Bid timing rules, extension on late bids |
| Registration, referral, promotion | Fake accounts farming credit | OAT-019 Account Creation | Credit only after verified activity; referrals per device and payment instrument |
| Comment, review, message | Spam and fake reviews | OAT-017 Spamming | Posts per account age; first posts held for review |
| Login | Testing breached credentials | OAT-008 Credential Stuffing | Attempts per account and per credential pair |
| Catalogue, pricing, search | Bulk data harvesting | OAT-011 Scraping | Records per account per day; result caps |
| Payment authorisation | Testing stolen cards | OAT-001 Carding | Declines per account, per device, per card BIN |
Record for each flow: the business owner, the harm if automated (lost revenue, unfair allocation, regulatory exposure, brand damage), the acceptable volume per customer, and every endpoint that takes part, including mobile, partner and legacy versions.
Layer 2: choose the protection
| Mechanism (OWASP) | How it works | Strength | Trade-off |
|---|---|---|---|
| Device fingerprinting | Deny or challenge unexpected clients such as headless browsers | Forces attackers onto more costly tooling | Privacy review needed; weak for pure API clients |
| Human detection | CAPTCHA or behavioural biometrics such as typing patterns | Cheap to add at the riskiest step | Friction and accessibility cost; CAPTCHA solving services exist |
| Non-human pattern analysis | Flag sequences no person performs, such as add to cart and complete purchase in under a second | Works on API traffic without a browser | Needs flow-level telemetry and tuning |
| Blocking Tor exits and known proxies | Reputation lists applied to sensitive flows | Removes low-effort automation | Residential proxies evade it; can block privacy-conscious users |
| Securing machine-consumed APIs | Developer and B2B APIs get authentication, quotas and the same flow limits | Closes the bypass around the web front end | Requires partner onboarding and per-client quotas |
ASVS 5.0 turns these into verifiable requirements: V2.1.3 (business logic limits documented per user and globally), V2.3.2 (those limits implemented), V2.3.4 (locking so limited-quantity resources such as theatre seats or delivery slots cannot be double-booked), V2.4.1 (anti-automation against excessive calls) and, at Level 3, V2.4.2 (flows require realistic human timing). For detection layers and challenge design in depth, see the Bot Management Guide; for the fraud programme around it, see the Fraud Prevention Guide for Digital Businesses.
Identity and NHI requirements
API6 abuse is almost always carried out by non-human actors pretending to be people, or by real accounts driven by scripts. Identity decisions decide whether limits hold.
- Bind limits to durable identity signals: verified account, payment instrument, delivery address, phone number and device, not IP address alone. OWASP's scalping scenario used many IP addresses on purpose.
- Make account creation earn trust: email and phone verification, disposable domain blocking and sign-up rate limits before an account can reach a sensitive flow; release referral and promotion credit only after genuine activity. See the Identity Fraud Prevention Guide.
- Give legitimate automation its own identity: partners, aggregators and AI shopping agents should call a documented API with their own client credentials and quota, not scrape the consumer flow. That lets you allow good automation and block the rest. See the Bot vs AI Agent Traffic Management Guide.
- Apply flow limits to B2B keys too: a partner API key that can place orders without per-key unit caps is a scalping channel if the key leaks. See the API Key Management Guide.
- Use step-up, not blanket friction: challenge or re-authenticate only when risk signals cross a threshold, and use multi-party approval for the highest-value flows (ASVS V2.3.5).
Implementation steps
- Run a business flow workshop. Product, fraud, customer service and security list the flows, rank them by harm, and agree acceptable volumes per customer. Record the result in the API design documentation (ASVS V2.1.3).
- Map flows to endpoints. Trace each flow across web, mobile, partner and older API versions. An undocumented v1 checkout endpoint is the usual bypass; the API9 Improper Inventory Management Guide covers finding them.
- Enforce step order and business limits server-side. Reject requests that skip steps (ASVS V2.3.1), apply per-object limits in the domain service, and use transactional locking for scarce stock (V2.3.3, V2.3.4).
- Instrument the flow. Log each step with account, client ID, device identifier, session and timestamp, so time between steps and clustering can be analysed.
- Deploy detection in monitor mode. Turn on bot signals, timing rules and reputation checks in log-only mode for two to four weeks, including one real high-demand event if possible, and measure false positives against confirmed customers.
- Enforce in rings. Start with the highest-harm flow and the clearest signals; prefer graduated responses (slow down, challenge, queue, hold for review) over outright blocks; widen once false positives are acceptable.
- Prepare for peaks. For known launches, use virtual queues, per-account purchase caps and pre-registration; brief customer service on what blocked users will see.
- Plan rollback. Keep every rule behind a flag with a named owner, so a rule that blocks real customers during a launch can be switched to monitor mode immediately.
- Review after every event. Compare allocation (how many units went to accounts later flagged) and adjust limits and signals.
Small business or large platform
Smaller organisations usually get most protection from business rules they control directly: per-account and per-card limits, hold expiry, verified sign-up, delayed referral credit, and a managed bot protection layer on the two or three riskiest flows. Large platforms add a dedicated risk engine scoring every flow step, device intelligence, a fraud operations team with case management, and published partner APIs so legitimate automation has a sanctioned route.
Evidence and assessment
API6 does not show up in a standard vulnerability scan. Assessment means testing the flow as an attacker would, within agreed rules of engagement.
| Area | Evidence | Test |
|---|---|---|
| Flow inventory | Documented sensitive flows, owners, acceptable volumes | Interview owners; compare with API specification and traffic |
| Business limits | Per-object caps in code or configuration | Script the flow with one account beyond the cap; expect refusal |
| Distributed abuse | Limits on card, address, device and phone | Repeat across several test accounts sharing a payment instrument |
| Step order | Server-side state machine | Call the final step directly, skipping earlier ones |
| Alternative channels | Same limits on mobile, partner and legacy endpoints | Run the flow through each channel |
| Detection | Bot and timing signals, alerts, case records | Run a scripted flow at machine speed; confirm an alert or challenge |
Detection and metrics
- Share of scarce inventory going to flagged accounts: the outcome measure for scalping and denial of inventory.
- Median time between flow steps: sub-second checkout or sign-up sequences indicate scripts.
- Accounts per device, card or address cluster: clusters above a threshold indicate farming.
- Hold-to-purchase ratio: many holds and few purchases indicate denial of inventory.
- Referral credit later reversed: the cost of promotion abuse.
- False positive rate on challenged sessions: the customer cost of the controls, measured through support contacts and completed challenges.
Mapping to other frameworks
| Framework | Reference | Relevance to API6 |
|---|---|---|
| OWASP ASVS 5.0 | V2.1.3, V2.3.1, V2.3.2, V2.3.4, V2.3.5, V2.4.1, V2.4.2, V16.3.3 | Documented and enforced business limits; step order; locking scarce resources; multi-user approval; anti-automation; human timing; logging attempts to bypass anti-automation |
| OWASP Automated Threats | OAT-001, OAT-005, OAT-008, OAT-011, OAT-013, OAT-017, OAT-019, OAT-021 | Shared names for the abuse each flow invites |
| MITRE CAPEC | CAPEC-212 | Functionality misuse |
| MITRE ATT&CK v20 | T1110.004, T1136 | Credential stuffing against the login flow; create account (mass account creation) |
| NIST SP 800-53 Rev 5 | SA-8, SI-10, SI-4, AU-6 | Security engineering principles in design; input validation; system monitoring; audit review and analysis |
| NIST CSF 2.0 | ID.RA-05, PR.PS-06, DE.AE-02 | Risk understood from threats and business impact; secure development; analysis of adverse events |
| ISO/IEC 27001:2022 Annex A | 8.16, 8.26, 8.27 | Monitoring activities; application security requirements; secure system architecture and engineering principles |
| CIS Controls v8.1 | Control 16 | Application software security |
The OWASP API6 entry also points to API10:2019 Insufficient Logging and Monitoring: without flow-level logs, abuse of a sensitive flow looks like good trading.
Common pitfalls
- Protecting the web page, not the API behind it: a CAPTCHA on the checkout page does nothing if the mobile or partner API completes the same purchase without it.
- Request-rate limits as the only control: a scalper buying one unit per account across a thousand accounts never trips a per-account request limit. Limit the business object across identity signals.
- Relying on IP blocking: residential proxy networks make IP reputation a weak signal on its own; OWASP's own scenario distributes across IPs and locations.
- Paying incentives on sign-up: credit released at registration rewards account farming. Release it after verified, genuine activity.
- Blocking all automation: some automation is legitimate and some is your partners'. Without a sanctioned API route for it, blocks hurt customers and push good bots into evasion.
- No owner for the business rule: security tunes bot signals while nobody in the business owns "how many per customer". The limit stays undefined and the flow stays open.
Practitioner checklist
- Sensitive business flows are listed with owner, harm and acceptable volume per customer.
- Every endpoint in each flow is known, across web, mobile, partner and legacy versions.
- Per-object limits (per account, card, address, device, phone) are enforced server-side.
- Step order is enforced and scarce resources use transactional locking with hold expiry.
- Sign-up requires verification, blocks disposable domains and is rate limited; incentives pay out only after genuine activity.
- Bot signals, timing analysis and reputation checks run on the riskiest flows, with graduated responses.
- Partner, developer and AI agent traffic uses its own credentials and quotas, with the same flow limits.
- Flow steps are logged with identity and device data, and the metrics above are reviewed after every high-demand event.
- Every rule has a flag, an owner and a rollback to monitor mode.
Standards and references
- OWASP: API6:2023 Unrestricted Access to Sensitive Business Flows
- OWASP: API Security Top 10 2023
- OWASP: Automated Threats to Web Applications
- OWASP: Application Security Verification Standard 5.0
- OWASP: OAT-005 Scalping
- OWASP: OAT-021 Denial of Inventory
- MITRE: CAPEC-212 Functionality Misuse
Related NHI Mgmt Group resources: Top 10 API Security Risks · Bot Management Guide · Fraud Prevention Guide for Digital Businesses · Rate Limiting and API Abuse Guide · OWASP API Top 10 API4 Unrestricted Resource Consumption Guide