OWASP API6:2023, Unrestricted Access to Sensitive Business Flows, is about protecting actions that are legitimate but economically or operationally dangerous when used too often, too quickly, or through coordinated automation. It requires security teams to understand the business workflow—not just the endpoint.
What Is OWASP API6:2023?
The official OWASP API6:2023 guidance describes an API as vulnerable when it exposes a sensitive business flow without appropriately restricting access to it. OWASP highlights examples such as purchasing scarce products, creating posts, and making reservations.
The important word is business. A request can pass authentication, authorization, input validation, and schema checks while still being abusive. A customer may be allowed to create an account, reserve an appointment, redeem a reward, or purchase an item. The weakness appears when the system does not account for harmful repetition, automation, distribution across many identities, or manipulation of workflow timing.
The endpoint may work correctly
API6 is often not an implementation bug. The API performs the intended action, but the organization has not defined or enforced safe usage boundaries.
Impact is business-specific
The same automated behavior can be acceptable for one product and harmful for another. Product owners must help define the risk.
Abuse may be authenticated
Valid accounts, partner credentials, service identities, and legitimate client software can all be used to automate a sensitive flow.
Single requests may look normal
Detection often depends on correlation across time, identities, tenants, devices, endpoint sequences, and business outcomes.
How API6 Differs from Related API Risks
API6 overlaps with rate limiting, authorization, fraud, bot management, and resource protection, but it is not identical to any one of them. Clear classification helps teams choose the right owner and control.
| Risk area | Primary question | Example | Main control focus |
|---|---|---|---|
| API6: Sensitive business flows | Can legitimate functionality harm the business when used excessively or automatically? | Reserving every appointment slot | Business rules, workflow limits, anti-automation, outcome monitoring |
| API4: Resource consumption | Can requests exhaust technical resources or trigger uncontrolled costs? | Generating expensive reports repeatedly | Resource quotas, payload limits, cost controls, timeouts |
| Broken authorization | Can a caller perform an action or access an object they should not be allowed to use? | Changing another customer’s reservation | Object, property, and function-level authorization |
| Bot and automated abuse | Is software performing unwanted actions at scale? | Automated account creation | Layered bot signals, identity, reputation, behavioral controls |
| Fraud | Is the actor using deception to obtain financial or business value? | Referral-credit farming | Eligibility, linkage analysis, transaction and fraud controls |
One event can fall into several categories. Repeated exports may consume compute resources, expose data, and violate business policy at the same time. Classification should guide the response, not force teams to choose only one label.
Examples of Sensitive Business Flows
A useful inventory starts with actions that affect scarcity, money, identity, reputation, customer access, or downstream operational cost. The examples below are defensive review scenarios, not instructions for abuse.
| Workflow | Potential abuse pattern | Possible business impact | Useful controls |
|---|---|---|---|
| Purchase or ticketing | Automated acquisition of limited inventory | Scalping, unfair access, customer dissatisfaction | Per-identity limits, queueing, inventory rules, risk-based verification |
| Booking or reservation | Holding many slots without genuine intent | Unavailable appointments, lost revenue, operational disruption | Hold expiry, confirmation rules, account and device limits |
| Account creation | Large numbers of low-trust accounts | Spam, promotion abuse, moderation cost | Progressive verification, velocity controls, reputation signals |
| Referral, coupon, or loyalty redemption | Coordinated use across linked identities | Financial loss and distorted campaign results | Eligibility rules, linkage analysis, redemption quotas |
| Posting, voting, reviewing, or messaging | Automated or coordinated content actions | Spam, manipulation, trust damage | Account reputation, feature-level limits, content and sequence signals |
| Exports and report generation | Repeated bulk operations through an authorized account | Data exposure, cost growth, service degradation | Purpose-based access, job quotas, approval and audit trails |
| Password recovery or verification | Repeated triggering of customer-facing messages or checks | Harassment, support load, messaging cost | Identity-aware throttling, cooldowns, abuse monitoring |
| Partner or machine API | Use beyond the intended commercial or operational contract | Unexpected cost, resale, data overuse, capacity pressure | Client identity, scoped access, contract quotas, usage analytics |
OWASP’s Automated Threats to Web Applications project provides additional vocabulary for automated misuse, including account creation, scalping, spamming, scraping, and skewing. Its 2026 update reinforces the value of a shared language across security, engineering, product, and business teams.
How to Assess API6 Exposure
Assessment should begin with product and business impact, then move into engineering. OWASP explicitly recommends planning mitigation in two layers: the business identifies flows that could be harmful when overused, and engineering selects suitable protections.
1. Build a sensitive-flow inventory
Map workflows rather than isolated endpoints. A purchase may span inventory lookup, cart creation, reservation, payment, and confirmation. Record the flow owner, users, client types, downstream services, business value, scarcity, cost, and expected completion pattern.
2. Define acceptable use
Document normal volume and timing by user, tenant, partner, account age, device, region, service identity, and commercial plan. Define what is harmful, what is merely unusual, and which exceptions are legitimate.
3. Model abuse cases
Turn important business rules into defensive test cases. The OWASP Abuse Case Cheat Sheet recommends expressing how application functionality could be misused and verifying that the relevant business rule is enforced.
4. Trace every entry point
Review web, mobile, public API, partner API, internal service, GraphQL, webhook, batch, and administrative paths. A control implemented only in a frontend or one gateway route can be bypassed through another supported entry point.
5. Define measurable outcomes
Choose metrics that show both abuse reduction and customer impact: blocked or challenged abusive activity, false-positive rate, reservation completion, promotion loss, account quality, support tickets, alert precision, and time to investigation.
Sensitive-flow inventory fields: - Flow name and business owner - Endpoints and expected sequence - Users, tenants, partners, and machine clients - Scarcity, cost, revenue, fairness, and trust impact - Normal volume, timing, conversion, and completion behavior - Abuse cases and expected-denied conditions - Existing controls and known exceptions - Runtime signals, alert owner, and response playbook - Success metrics and review frequency
How to Prevent Unrestricted Access to Sensitive Business Flows
No single control prevents API6. The strongest design combines business rules, identity, velocity, sequence, reputation, cost, and outcome signals. The exact combination depends on the workflow and the harm being prevented.
| Control layer | What to implement | Why it matters |
|---|---|---|
| Business rules | Eligibility, purchase limits, hold expiry, redemption policy, purpose constraints | Directly expresses what the business considers acceptable |
| Identity and authorization | Strong client identity, scoped tokens, tenant isolation, server-side checks | Prevents anonymous or overprivileged use and supports accurate attribution |
| Feature-level quotas | Limits by action, user, account, tenant, partner, device, plan, and time window | Broad IP limits alone miss distributed and authenticated abuse |
| Workflow validation | Expected sequence, state transitions, idempotency, replay checks, expiry | Stops requests that are individually valid but inconsistent with the process |
| Anti-automation | Behavior, device, reputation, client integrity, and non-human timing signals | Raises the cost of automated misuse and supports risk scoring |
| Proportional friction | Step-up verification, queueing, confirmation, approval, or review | Protects high-risk actions without adding equal friction to every user |
| Cost and resource controls | Budgets, concurrency limits, payload limits, job quotas, circuit breakers | Prevents API6 activity from becoming an API4 or availability incident |
| Observability and response | Business metrics, correlated events, owner routing, runbooks, feedback loops | Detects low-and-slow or distributed patterns and improves controls over time |
Do not rely on frontend controls
Buttons, client-side timers, hidden fields, and mobile application logic do not enforce business policy. Server-side services must validate workflow state and limits for every supported entry point. The OWASP REST Security Cheat Sheet similarly warns against relying on frontend logic to enforce sequencing.
Use rate limiting at the feature level
Global request limits are useful for infrastructure protection, but API6 needs controls tied to the business action. The OWASP Business Logic Security Cheat Sheet recommends rate limiting and monitoring at the feature level, not only at authentication.
Protect machine-consumed APIs explicitly
Developer, B2B, partner, and service-to-service APIs may not support browser-based challenges. Use client identity, signed or scoped credentials, contract-specific quotas, purpose restrictions, audit trails, and anomaly detection. OWASP specifically notes that machine-consumed APIs can be attractive targets when they lack equivalent protection mechanisms.
Apply privacy-aware anti-automation
Device and behavioral signals can help, but they can also introduce privacy, accessibility, and false-positive concerns. Document the purpose, minimize collected data, restrict retention, test across legitimate client types, and provide exception and recovery paths.
Runtime Detection and Incident Response
API6 is difficult to detect from a single request. Runtime analytics should correlate behavior across the full workflow and combine technical evidence with business context.
Sequence and state
Track expected steps, skipped stages, repeated transitions, impossible timing, idempotency, retries, and incomplete workflows.
Identity and linkage
Correlate users, accounts, tenants, API keys, devices, sessions, payment instruments, and service identities where lawful and appropriate.
Velocity and distribution
Measure short bursts, sustained low-rate behavior, coordinated populations, quota evasion, and shifts from established baselines.
Business outcomes
Monitor inventory holds, conversion, redemptions, account quality, messaging cost, job cost, cancellation, and customer impact.
Example SIEM event structure
{
"event_category": "api_business_flow_abuse",
"owasp_category": "API6:2023",
"workflow": "promotion_redemption",
"endpoint_sequence": ["POST /cart", "POST /promotions/validate", "POST /promotions/redeem"],
"principal_type": "customer_account",
"tenant": "consumer_platform",
"observation_window": "30m",
"signals": ["linked_identity_velocity", "repeated_sequence", "low_account_age"],
"business_impact": "promotion_loss_risk",
"risk_score": 84,
"owner": "commerce-platform-team",
"recommended_action": "review eligibility, linkage, quota, and exception handling"
}Response workflow
- Validate the flow and impact. Confirm the endpoint sequence, identities, business rule, customer effect, and whether the pattern is genuinely harmful.
- Contain proportionally. Apply a temporary quota, step-up check, hold release, client suspension, or other approved control without broadly disrupting legitimate users.
- Fix the business rule. Update eligibility, sequence, state, identity, quota, or contract logic at the authoritative service layer.
- Review related entry points. Check mobile, partner, legacy, batch, and internal routes for the same missing control.
- Measure the result. Confirm lower abuse, acceptable false positives, stable conversion, useful alerts, and clear ownership.
Useful supporting practices include API behavior analytics, API risk scoring, and centralized SIEM log forwarding.
How to Test API6 Safely
API6 testing should be authorized, business-approved, and designed to avoid customer or production harm. Testing is most useful when it verifies explicit business rules rather than simply sending large volumes of traffic.
| Test area | Defensive validation | Expected evidence |
|---|---|---|
| Allowed use | Normal user and partner workflows complete without unnecessary friction | Successful sequence, accurate audit trail, stable latency |
| Per-feature limits | Repeated actions are constrained by the correct identity and business dimension | Predictable rejection or challenge and a useful event |
| Distributed behavior | Controls correlate activity that is split across sessions or accounts when policy allows | Risk increases based on linkage and business outcome, not IP alone |
| Workflow sequence | Skipped, repeated, expired, or out-of-order states are rejected server-side | Consistent response and logged reason |
| Exception paths | Customer support, trusted partners, and accessibility cases have governed exceptions | Approval, scope, expiry, monitoring, and revocation |
| Operational readiness | Alerts reach the correct team with enough evidence to investigate | Owner, workflow, identity context, impact, and recommended action |
API6 Implementation Plan
A phased approach keeps API6 work practical and measurable.
Phase 1: Discover
Inventory sensitive workflows, entry points, owners, clients, downstream dependencies, and current protections.
Phase 2: Define
Agree on acceptable use, harmful outcomes, exceptions, business metrics, and expected-denied scenarios.
Phase 3: Enforce
Implement server-side business rules, feature-level quotas, workflow state, identity, and proportional anti-automation controls.
Phase 4: Observe
Correlate runtime signals, business outcomes, alert ownership, and response playbooks across all entry points.
Phase 5: Improve
Measure abuse reduction, customer impact, false positives, investigation time, and control bypasses after every change.
OWASP API6:2023 Prevention Checklist
| Area | Question | Priority |
|---|---|---|
| Flow inventory | Have we mapped workflows that affect money, scarcity, identity, trust, availability, or cost? | Required |
| Ownership | Does every sensitive flow have business, product, engineering, security, and operational owners? | Required |
| Acceptable use | Are normal and harmful patterns defined by identity, tenant, client, sequence, volume, timing, and outcome? | Required |
| Server-side rules | Are eligibility, state, sequencing, expiry, and limits enforced in authoritative services? | Required |
| Feature quotas | Are limits tied to the business action rather than only global IP or request counts? | Required |
| Machine APIs | Do partner and service APIs have scoped identity, contract quotas, audit trails, and anomaly detection? | Required |
| Runtime analytics | Can we correlate sequences, identities, velocity, distribution, and business outcomes? | Recommended |
| Testing | Do release tests include allowed, denied, exception, reset, distributed, and low-rate scenarios? | Recommended |
| Response | Do alerts include impact, owner, evidence, recommended action, and a tested runbook? | Recommended |
| Frontend-only controls | Are any important limits enforced only in a website or mobile client? | Remove dependency |
| Rate-limit-only strategy | Are broad thresholds being used without business context or outcome monitoring? | Avoid alone |
Common API6 Prevention Mistakes
- Treating API6 as only a rate-limit problem. Thresholds must reflect the workflow, identity, scarcity, cost, and business outcome.
- Leaving product and fraud teams out. Security cannot define harmful use without business context.
- Protecting only the browser path. Mobile, partner, GraphQL, batch, and internal APIs may expose the same action.
- Assuming authenticated traffic is safe. Valid accounts and API keys can still automate harmful behavior.
- Blocking on one weak signal. IP address, user agent, or CAPTCHA outcome alone is easy to misinterpret and can harm legitimate users.
- Ignoring low-and-slow behavior. Distributed activity can remain below simple limits while still creating business impact.
- Alerting without an owner. Events need the workflow, impact, evidence, responsible team, and next action.
- Failing to measure customer impact. A control that stops abuse but damages legitimate conversion is not complete.
Authoritative References
Conclusion
OWASP API6:2023 is a reminder that secure requests do not automatically create safe business outcomes. An API can be authenticated, authorized, and technically correct while still allowing harmful automation of purchasing, booking, account creation, redemption, posting, exporting, or other valuable actions.
Effective protection begins with a sensitive-flow inventory and clear ownership. It then combines server-side business rules, feature-level quotas, identity and sequence controls, proportional anti-automation, runtime correlation, business metrics, safe testing, and operational response. The result should reduce abuse without unnecessarily blocking legitimate customers or partners.
FAQ
What is OWASP API6:2023 Unrestricted Access to Sensitive Business Flows?
OWASP API6:2023 covers APIs that expose business-critical workflows without enough protection against excessive or automated use. The requests may be valid and authorized, yet still harm revenue, fairness, availability, trust, or operations when repeated at scale.
What is a sensitive business flow?
A sensitive business flow is an API-enabled action whose excessive or automated use can materially harm the organization or its users. Examples include purchasing scarce inventory, creating accounts, making reservations, redeeming promotions, posting content, voting, exporting data, or triggering costly downstream work.
How is API6 different from a traditional software vulnerability?
API6 often involves legitimate functionality rather than malformed input or a coding defect. The weakness is that the system does not sufficiently restrict how a valuable workflow can be repeated, automated, sequenced, or distributed across identities and devices.
How is API6 different from OWASP API4:2023 Unrestricted Resource Consumption?
API4 focuses on excessive consumption of technical resources such as CPU, memory, bandwidth, storage, or paid third-party services. API6 focuses on business harm caused by excessive use of a workflow, such as scalping inventory, creating fake accounts, or reserving all available appointments. One incident can involve both categories.
Is API6 the same as broken authorization?
No. Broken authorization allows a caller to perform an action or access an object they should not be allowed to use. With API6, the caller may be permitted to perform the action, but the business has not adequately controlled excessive, automated, or abusive use.
Are rate limits enough to prevent API6?
Rate limits are useful but rarely sufficient on their own. Stronger protection combines feature-level limits, user and tenant quotas, workflow sequencing, eligibility rules, velocity and reputation signals, bot and automation detection, proportional verification, and monitoring of business outcomes.
What are common examples of API6 abuse?
Common examples include inventory scalping, appointment or ticket hoarding, fake account creation, referral and promotion abuse, automated posting or voting, bulk scraping through legitimate endpoints, repeated report generation, and machine-driven workflows that create disproportionate cost or operational load.
How should machine-to-machine and partner APIs be protected?
Use strong client identity, scoped authorization, contract-specific quotas, purpose-bound access, replay resistance where appropriate, schema and sequence validation, cost and volume monitoring, and clear exception handling. Machine-consumed APIs should not be assumed safe simply because they are not used through a browser.
How can runtime monitoring detect business-flow abuse?
Runtime monitoring can correlate workflow steps, identities, tenants, devices, timing, volume, success rates, account age, inventory effects, and other business signals. The goal is to find patterns that look normal at the single-request level but become suspicious across a sequence or population.
How should API6 be tested safely?
Test only with authorization, controlled accounts, documented business scenarios, known limits, and agreed stop conditions. Validate allowed and expected-denied cases, distributed and low-rate patterns, workflow sequencing, quota resets, exception paths, and the quality of resulting logs and alerts.
Who should own API6 prevention?
Ownership is shared. Product and business teams define harmful use; engineering implements workflow controls; fraud and abuse teams contribute risk signals; AppSec validates design and tests; platform teams enforce shared controls; and the SOC operates monitoring and response.
What should an API6 alert contain?
A useful alert should identify the workflow, endpoint sequence, caller and tenant context, relevant velocity or automation signals, affected business metric, confidence or risk score, evidence window, responsible owner, and a recommended investigation or containment action.
Protect sensitive API workflows with runtime context
Ammune helps teams discover API workflows, analyze runtime behavior, identify automation and business-logic abuse signals, prioritize findings, and send investigation-ready evidence to security operations.