API6:2023 covers legitimate API flows that become harmful when automated at scale, such as buying limited stock, reserving seats or farming referral credit. Nothing is technically broken. The fix starts with the business choosing which flows matter, then engineering picks controls to match.
What makes this different
Most API risks are bugs: a missing check, an exposed field. API6 is about use. Attackers study the business logic behind an API, find a flow that excessive use can hurt, and automate it. OWASP notes the damage is mainly to the business, such as blocking real customers or distorting a game economy, rather than to the system.
OWASP's test is simple: an endpoint is vulnerable if it exposes a sensitive business flow without appropriately restricting access to it.
Three scenarios from OWASP
- A bot spread across many addresses buys most of a limited-stock console on release day and resells it for more.
- A user reserves 90 percent of a flight's seats at no cancellation cost, cancels late to force discounts, then buys one cheap ticket.
- A script creates fake sign-ups to collect referral credit, then uses it for free rides or sells the accounts.
Step one: pick the flows
OWASP splits mitigation into a business layer and an engineering layer. The business layer comes first. Ask:
- Which flows cost us money, stock or trust if used a thousand times faster than a human could?
- Which flows create something scarce or resalable?
- Which flows award value, such as credits, discounts or access?
Make a short list. You cannot put a challenge on every endpoint.
Step two: choose controls
OWASP lists several engineering options. Here is how to think about them.
- Device fingerprinting: Fits when: You can deny unexpected clients such as headless browsers; Watch out for: Raises attacker cost, not a guarantee
- Human verification (captcha or behavioural signals): Fits when: A person is the legitimate user; Watch out for: Friction for real users
- Behavioural analysis: Fits when: Speed is a tell, such as cart to checkout in a second; Watch out for: Needs tuning to avoid false positives
- IP blocking: Fits when: Known proxy and Tor exit traffic is clearly unwanted; Watch out for: Easy to rotate around
- Limits on machine facing APIs: Fits when: Partner and developer APIs expose the same flow; Watch out for: Often forgotten because they lack full protections
The last row matters. Developer and B2B APIs often skip the checks the consumer app has, so attackers use them instead.
Step three: measure
Pick a metric per flow, for example purchases per account per hour, or referral sign-ups per device. Alert when it departs sharply from normal. Without a baseline you will not notice abuse until customers complain.
Combine with resource limits
Business flow protection sits next to rate limits and spend caps. The two overlap but answer different questions. See the resource limits checklist.
Quick check
Is API6 a vulnerability scanners will find?
Rarely. It depends on business context, so it needs a human decision about which flows are sensitive.
Does a captcha solve it?
It raises the cost for bots on flows where a person is the user. It does nothing for partner APIs and can be bypassed, so use it with other controls.
Safeguard's asset discovery can help you find the endpoints and services that expose such flows, and the free scan at gold.safeguard.sh/scan checks dependencies. Deciding which flows are sensitive stays with your team.
Sources
Last reviewed: 19 October 2026.
