Abuse prevention
Credential stuffing, fake accounts and scraping use your product as designed. Why per-IP limits fail, which signals work, and why false positives dominate at scale.
25 min6 steps
By the end you can
- Explain why per-IP rate limits alone fail against credential stuffing, and estimate an attack's pace
- Combine account, credential, device and velocity signals into layered defences
- Calculate the share of blocks that hit legitimate users, given base rates
- Choose graduated friction proportionate to risk instead of a single block decision
Attacks that use the product as designed
Abuse is your own login, sign-up, search and checkout used at scale with bad intent. Every request is valid; the signal is the pattern.
Credential stuffing
- Leaked passwords replayed
Fake accounts
- Spam, promo abuse
Scraping
- Prices, content
Card testing
- Tiny buys, many cards
Credential stuffing beats per-IP limits
Credential stuffing replays leaked username and password pairs, betting on reuse. Residential proxy pools make each IP look like one household, so per-IP limits barely help.
Loading question…
Layer the signals
No single signal holds. Stack signals that are costly to fake together.
Breached-password check
- Block known leaks
- k-anonymity range query
MFA
- Leaked password not enough
Velocity per account, device, global
- Not only per IP
Per-IP limit alone
- Proxies dodge it
- Hurts shared NATs
The base-rate trap
Most traffic is legitimate, so even a 1% false-positive rate can block more good users than bad. Compute the share of blocks that are false.
Abusive
1,000
catch 90%: 900 blocked
Good users hit by 1% FPR
9,990
Blocks that are wrong
92%
9,990 / 10,890
Loading question…
Graduated friction
Respond in proportion to risk. Never reveal which signal fired.
Check your mastery
Score 80% or more.
Mastery check
4 questions on fresh variants. One attempt each, no time limit. Score 80% or more to master the lesson.
Next: multi-tenancy isolation.
Answer this step to continue.