API6:2023 — Unrestricted Access to Sensitive Business Flows

QUESTION 01 OF 05

What is the key difference between API4 (Unrestricted Resource Consumption) and API6 (Unrestricted Business Flow Access)?

Correct — API4’s damage is measured in server metrics: CPU, memory, cloud costs, downtime. API6’s damage is measured in business outcomes: revenue lost to scalpers, fraudulent referral payouts, real users excluded from purchases. The server can be perfectly healthy while API6 abuse is destroying the business. The defenses are also different: API4 needs infrastructure-level rate limits; API6 needs business-level rules and verification.

Not quite — both risks can involve authenticated or unauthenticated clients, and both affect REST APIs. The core difference is where the damage lands. API4: the server suffers (goes down, costs spike, data is scraped). API6: the business suffers while the server is fine (bots got all the tickets; the infrastructure handled it perfectly).

QUESTION 02 OF 05

In the Ticketmaster/Taylor Swift incident, why didn’t traditional security controls (rate limiting, authentication) stop the bots?

Correct — the bots were doing exactly what authentication and rate limiting are designed to permit: authenticated users making valid requests at a reasonable rate. Traditional security controls passed all of their requests because the requests were legitimate. The missing controls were business-level: how many tickets per account, how many carts per identity, how long can inventory be held before it’s released.

Not quite — the bots did have valid accounts and valid authentication. The security controls worked as designed. The gap was in business-level controls: no per-account ticket limit meant bots could hold unlimited inventory; no cart timeout meant they could hold it indefinitely. These are business rules, not security rules — and that’s what makes API6 distinct.

QUESTION 03 OF 05

A retail site shows “Limit: 1 per customer” on the product page. A bot purchases 500 units by calling the checkout API directly with quantity=500. What was the root cause?

Correct — this is a clean example of a UI limit that is not an API limit. The checkout API accepted the request with quantity=500 because the server had no business rule rejecting it. The fix is one line in the API handler: if quantity > MAX_PER_ORDER, return 422. Business rules must live in the API, not the frontend — this principle appears in both API3 (mass assignment) and API6 (business flow limits).

Not quite — no exploit, no injection, no rate limit violation. The bot called the API directly with a valid account and a valid request body — just with quantity=500 instead of 1. The API accepted it because there was no server-side check for the quantity limit. The limit only existed in the UI, which the bot bypassed entirely by calling the API endpoint directly.

QUESTION 04 OF 05

Why can’t security logs alone detect an API6 attack in progress?

Correct — because API6 attacks use valid accounts, valid tokens, and valid requests, they generate no authentication failures, no authorization errors, and no rate limit violations. The security logs look completely normal. The only observable signal is in business data: tickets selling out in 3 seconds instead of 45 minutes, 500 referrals processed in one hour, inventory depletion at 100x the normal rate. Detecting API6 requires monitoring business metrics — which is typically owned by product or fraud teams, not security.

Not quite — the issue is that API6 attacks produce no security signals at all. Valid accounts, valid tokens, valid requests, successful responses. Security logs only see what went wrong at the security layer — and nothing did. The attack shows up in inventory levels, referral counts, and account creation rates — business metrics that security dashboards typically don’t display.

QUESTION 05 OF 05

Why is CAPTCHA alone insufficient to stop sophisticated sneaker bots?

Correct — CAPTCHA raises the cost of bot operations but doesn’t eliminate them. When the value of what the bot is acquiring exceeds the cost of solving the CAPTCHA (which is almost always true for sneakers, tickets, or referral bonuses), bots remain profitable. CAPTCHA is one layer of defense that should be combined with device fingerprinting, per-account quantity limits, and phone verification for meaningful protection.

Not quite — CAPTCHAs aren’t bypassed by API exploits or browser blocks. They’re solved by CAPTCHA-solving services that use human workers to complete the challenges for $1–$3 per 1,000 solves. A bot that profits $300 per sneaker pair can afford to pay $0.003 per CAPTCHA hundreds of times over. CAPTCHA adds friction and cost — but when the economics still work for the bot operator, it doesn’t stop them.