API6: Prevention guidance assumes abuse can be separated from legitimate use by detecting non-human clients

[alienatix]

Engineering controls in API6:2023 "How To Prevent" works by classifying the client: device fingerprinting, human detection (CAPTCHA/biometrics), non-human timing patterns, and blocking Tor/proxy IPs. That model breaks when the automated client is itself legitimate: a first-party or approved third-party app, a developer/B2B integration, or a purchasing assistant acting under a valid user grant.
As AI assistants increasingly shop, book, and transact through APIs on users' behalf, legitimate automated traffic is becoming the norm rather than the exception, so API6 defenses that treat "automated" as a proxy for "malicious" will stop both blocking abuse and permitting legitimate use.

Proposed changes

1. "Is the API Vulnerable?" Add a condition:

The API is also vulnerable if the only restriction on a sensitive business flow is distinguishing human from automated clients, while authorized automated clients (partner integrations, developer APIs, or client applications acting on a user's behalf) can access the same flow.

2. "How To Prevent" Add business-layer controls that hold regardless of client type, and present the existing bot-detection bullets as one layer rather than the whole defense:

• Enforce limits on the business object, not the request: per-account, per-payment-instrument, per-shipping-address, or per-beneficiary caps on quantity, value, or frequency for each sensitive flow.
• Apply aggregate quotas per client application, so one approved integration can't consume a disproportionate share of a scarce resource (stock, seats, time slots, promotional budget).
• Add commitment cost to flows that can be hoarded and released, such as deposits or cancellation fees.
• Require step-up confirmation by the account holder, through a channel the client can't complete on its own, for high-value or irreversible actions.
• Scope automated clients' grants to exclude sensitive flows by default, and allow them per flow.

3. New scenario (suggested):

A retailer lets approved third-party shopping apps place orders on behalf of users via OAuth. For a limited-stock product launch, the retailer relies on CAPTCHA and bot detection on its own web checkout, but exempts approved apps from these checks. A reseller enrolls hundreds of real accounts in an approved app and schedules purchases for release time. Each order is authenticated, authorized, and arrives through a legitimate client, so none of the bot-detection controls trigger, and the reseller acquires most of the stock. Per-account and per-shipping-address purchase limits, plus an aggregate quota per client application, would have bounded the impact.

Scope note

This proposes new guidance and a new scenario, so I understand it would probably target the next edition rather than 2023. Happy to open a PR once there's agreement on direction.

[llegaz]

I do not think API Top 10 purpose was to cover all scenario possible nor it is dedicated to shopping apps but maybe I'm wrong.

But you certainly make a point that it should be clear on the docs that API owners should design and adapt to their specific need, user audience and so on.

[alienatix]

Thanks @llegaz, that's fair. The scenario was only an illustration. All four engineering controls in "How To Prevent" work by separating humans and bots. For APIs where automated access is intended, those controls either don't apply or get disabled by design, and the section doesn't say what to do instead.

Maybe, to keep it simpler, adding something like this to "How To Prevent" will do the job:

Choose protections based on each flow's audience. Where automated access to a sensitive flow is expected, such as partner, B2B, developer, or delegated clients, controls that detect non-human clients are not sufficient on their own; limit the flow itself instead, for example, with per-account or per-payment-method caps, per-client-application quotas, or confirmation by the account holder for high-value actions.