Chapter 74 — Abuse, fraud, bots, and business-logic defense
In one sentence
Abuse defense protects legitimate features from being used at illegitimate scale, sequence, or intent.
Why this is different from classic appsec
The request may be valid:
POST /signup
POST /login
POST /promo/redeem
POST /transfer
GET /inventory
The abuse is in the pattern:
- 10,000 accounts created from rotating IPs;
- credential stuffing with real leaked passwords;
- promo credits redeemed across synthetic identities;
- scraping a public but expensive endpoint;
- refund policy gamed through edge cases;
- marketplace reputation manipulated by colluding accounts.
Abuse controls
| Control | Use carefully because |
|---|---|
| Rate limits | Attackers distribute across accounts/IPs/devices |
| Device fingerprinting | Privacy and false positives matter |
| CAPTCHA | Accessibility, solver farms, UX cost |
| Velocity rules | Need baselines and appeal paths |
| Graph analysis | Powerful for collusion, expensive to operate |
| Step-up auth | Good for risky actions, bad if always-on |
| Manual review | High precision, but slow and costly |
Scenario: promo-code abuse
Attack path:
- create many accounts;
- add virtual cards;
- redeem first-purchase promo;
- transfer value to one destination;
- abandon accounts.
Defenses:
- promo eligibility tied to more than email/account age;
- velocity limits across device, payment instrument, shipping address, ASN;
- graph links between accounts;
- delayed settlement for high-risk patterns;
- abuse metrics by campaign.
Common mistakes
- Treating fraud as "just rate limiting."
- Blocking by IP only.
- Making rules invisible to customer support.
- Not measuring false positives and business impact.