Protect sensitive business flows

A perfectly valid request can still abuse the product. Buying all limited stock through automation is a business-flow attack: every individual request passes every technical check, and the damage lives in the aggregate.

Find the flows worth attacking

Identify scarce, valuable, or irreversible actions: purchasing limited inventory, sending invitations, reserving slots, triggering password reset emails, claiming referral rewards. For each one, ask what happens when a scripted client runs it a thousand times an hour.

An invitation endpoint can pass every schema check while sending 10,000 emails. The attacker pays nothing. You pay the provider bill and lose sending reputation for your whole domain.

Layer limits on the flow, not just the endpoint

Add per-identity and contextual limits, idempotency, confirmation, monitoring, and manual review where impact warrants it:

invitations:
  per-account:      50 / day
  per-destination:  3 / week    # the same inbox cannot be flooded
  per-signup-ip:    5 / hour    # fresh accounts do not reset limits

The per-destination limit matters more than it looks. Creating ten accounts defeats a per-account cap, but the target address stays the same across all of them.

A CAPTCHA alone may slow bots, but it does not cap cost after a valid session is automated. Avoid defenses that only slow honest users.

Verify the cap holds:

for i in $(seq 1 60); do
  curl -s -o /dev/null -w "%{http_code}\n" \
    -X POST https://api.example.com/invitations \
    -H "Authorization: Bearer $TOKEN" \
    -d '{"email":"person'$i'@example.com"}'
done
# 201 for the first 50, then 429 — and exactly 50 emails delivered

Count the actual deliveries in the email provider’s log. A limiter that returns 429 after the send already happened protects nothing.

Leave a recovery path

Limits need a recovery path for legitimate spikes. A real customer launching a company-wide rollout will hit the invitation cap on day one. Record who can approve a larger campaign, how long the exception lasts, and which signal reveals continued abuse.

Set per-account and per-destination limits for invitations and record the expected email count. Replay requests across several sessions and prove delivery stops, an event is logged, and normal recovery remains possible.