The one-sentence version
Many attacks do not exploit vulnerabilities but rather exploit "volume": using leaked passwords to attempt mass logins (credential stuffing), repeatedly requesting SMS verification codes to incur massive SMS costs, mass-registering accounts to exploit promotions, or making high-frequency calls to expensive AI interfaces. Every single request is "legitimate," but together they are catastrophic. Defense relies on rate limiting (restricting the number of requests within a unit of time) and abuse prevention (identifying and treating suspicious traffic differently). The key is choosing the right dimensions for rate limiting: by IP, by account, by phone number, by device, and deciding at which layer to apply the limits.
This article has three layers:
- Layer 1: The Intuition: Purchase limits and queuing
- Layer 2: Real-World Use: Credential stuffing, SMS bombing and SMS cost attacks, and AI API theft
- Layer 3: Principles and Engineering details
Layer 1: The Intuition
1.1 Purchase limits and queuing
When a supermarket has a sale, they might say "limit two items per person," or a bank counter might use a "take a number and wait in line" system. These rules have little impact on normal customers but prevent someone from clearing out the entire shelf at once or paralyzing the service counter.
Network services work the same way: a normal user might fail to log in a few times a minute or request a verification code once or twice; a script can attempt tens of thousands of times per minute.
1.2 Abuse of "legitimate" requests
| Attack | Individual request appearance | Combined consequence |
|---|---|---|
| Credential stuffing | A standard login attempt | Using account/password pairs leaked from other sites to attempt mass logins; once successful, accounts are hijacked |
| SMS bombing | A normal "send verification code" request | The victim's phone is flooded with verification codes |
| SMS pumping | Same as above | The attacker makes you send large volumes of SMS to high-cost number ranges they control, splitting the revenue with the carrier while you pay the bill |
| Promotion exploitation | A normal registration | Mass-registering new accounts to claim discounts/rewards |
| API theft | A normal API call | Stolen API keys are used to run massive amounts of expensive AI requests |
Layer 2: Real-World Use
- 23andMe (2023): Attackers used passwords leaked from other websites to perform credential stuffing, logging into approximately 14,000 accounts; they then used the platform's "DNA Relatives" feature to indirectly obtain personal information for about 6.9 million users. This demonstrates how the impact of credential stuffing can be amplified by product features.
- SMS pumping: Many internet companies have publicly stated they have lost significant amounts in SMS fees due to the abuse of verification code interfaces. Attackers often target high-cost international number ranges.
- AI API theft: Developers leak API keys in frontend code or public repositories (see Secret Scanning), and they are used to run massive requests within hours, generating huge bills. Consequently, many cloud platforms now provide usage limits and budget alerts.
- Standard for login pages: Requiring CAPTCHA after several failed attempts, introducing response delays, or temporary account locking is a default configuration for almost all large websites.
Layer 3: Principles and Engineering
3.1 Token Bucket Algorithm
The most commonly used rate-limiting algorithm:
- Each "bucket" (e.g., per IP, per account) can hold a maximum of tokens;
- Tokens are automatically replenished at a rate of per second; if the bucket is full, no more are added;
- Each request consumes one token; if no tokens are available, the request is rejected (or queued).
Login interface: , (replenishing 1 per minute)
- A normal user occasionally enters a password wrong once or twice: there is a buffer in the bucket, so they feel no impact;
- An attack script attempts continuously: after 5 attempts, it can only try once more per minute, totaling about 1,440 attempts per day.
For credential stuffing that requires trying thousands of passwords, the speed is reduced by several orders of magnitude.
Its advantage is that it allows for short-term bursts (bucket capacity ) while limiting the long-term average rate ().
3.2 Rate limiting dimensions
| Dimension | What it prevents | Weakness |
|---|---|---|
| By IP | High-frequency requests from a single source | Attackers use large numbers of proxy IPs; many legitimate users may share one IP (company, school, mobile network) |
| By account | Brute-force attacks targeting a specific account | Credential stuffing involves "trying each account only once," so account-based limiting cannot stop it |
| By phone number / email | SMS bombing | Attackers switch numbers |
| By number range / country | SMS pumping | Requires business logic judgment |
| By device fingerprint | Attacks that switch IPs but not devices | Fingerprints can be spoofed; privacy concerns |
| Global | Overall anomalies (e.g., login failure rate suddenly increases 10x) | Requires alerting rather than direct rejection |
In practice, you must layer multiple dimensions and use global metrics as alerting signals (see Security Monitoring and Alert Fatigue).
3.3 Progressive friction
Do not start with a ban; instead, increase the difficulty incrementally (the same logic used in risk control scoring and friction design):
- Allow normally;
- Increase latency;
- Require CAPTCHA;
- Require additional verification (email confirmation, passkey);
- Temporary lock;
- Ban and manual review.
3.4 For specific scenarios
| Scenario | Measures |
|---|---|
| Credential stuffing | Check if passwords appear in known leaked databases; promote passkeys (see Passkey and Anti-phishing); require extra verification when login is successful but device/location is abnormal |
| SMS costs | Only send SMS to countries covered by the business; set limits for requests from the same number range or same IP; switch to email, app push, or passkey |
| API theft | Do not put keys in the frontend; set usage limits and budget alerts; rate limit by key (see Least Privilege and Key Management) |
| Registration abuse | Email and phone number verification; gradually roll out features for new accounts |
3.5 At which layer to limit
| Layer | Description |
|---|---|
| CDN / Edge | Earliest interception, protects the backend; but cannot see business semantics (e.g., "this login failed") |
| API Gateway | Unified rate limiting by key or by path |
| Application | Can combine with business logic (failure counts, account status); most precise |
Typically, all three layers should be present, with precision increasing as you move deeper into the stack.
Summary
| Layer | Key points |
|---|---|
| Essence | Every request is legitimate, but damage is caused by "volume" |
| Algorithm | Token Bucket: allows bursts, limits average rate |
| Dimensions | IP, account, number, number range, device, global; multi-dimensional layering |
| Strategy | Progressive friction; customized by scenario; multi-layer deployment |