API6:2023Unrestricted Access to Sensitive Business Flows
Slide 17 of 28
Part 3 · Attack ScenariosSlide 17
Slide 17 · The Pattern
No business rule said “stop.” The API didn’t know to.
Across every scenario: the API executed correctly. The business constraints were missing or unenforced.
The Missing Question

Every API6 attack succeeded because the API never asked: “Is this activity consistent with legitimate human use of this business flow?”

Not “is this request valid?” — it was. Not “is the user authenticated?” — they were. Specifically: is this actor behaving in a way that our business model intended this flow to support?

The pattern in each scenario
Ticketmaster — no cart hold limit: how many tickets can one account hold simultaneously?
Sneaker bots — no completion time floor: can a checkout complete in 200ms?
Referral fraud — no account verification: are these real distinct people?
Quantity bypass — no server-enforced limit: how many units is one account allowed to buy?
The fix pattern
Define business rules explicitly: max units, max concurrent reservations, min completion time
Enforce rules at the API layer, not only the UI
Verify human identity before high-value actions
Monitor for machine-speed flow completion
Design incentive programs with fraud resistance from the start
← Back How do we fix it? →
📄 View sources