Rate Limiting & API Abuse Bugs

Rate limiting sounds boring — it's just "how many requests can you send." But missing or broken rate limits enable a whole family of real, paid bugs: brute-forcing, OTP bypass, resource abuse, and more. Let me show you why "no rate limit" is often the KEY that unlocks bigger bugs.

What's Rate Limiting?

Rate limiting is a control that caps how many times you can do something in a time window — like "max 5 login attempts per minute" or "max 3 password reset emails per hour." It exists to stop abuse.

When it's MISSING or weak, you can hammer an endpoint as fast as you want. And that ability to hammer is what turns several "protected" features into broken ones.

Why It Matters (The Chain Effect)

Missing rate limits are rarely THE bug — they're the ENABLER of bigger bugs:

• OTP/2FA brute-force: a 6-digit code has a million combos. With no rate limit, you just try them all and bypass 2FA. (This is a serious, high-paying bug.)
• Password brute-force: no limit on login = try thousands of passwords against an account.
• Coupon/gift-card brute-force: guess valid codes by trying millions.
• Reset-token brute-force: if reset tokens are short/weak, no rate limit means you can guess them.
• Resource abuse / cost attacks: hammering an expensive endpoint (like one that sends SMS or calls a paid AI) can rack up huge costs for the company.
• Enumeration: rapidly testing which usernames/emails exist.

How To Test It

1. Find a sensitive action (login, OTP verification, password reset, coupon redemption, SMS send)
2. Capture the request in Burp
3. Use Intruder (or a script) to send MANY requests rapidly
4. Did they all go through? Or did you get blocked/throttled after a few?
5. If there's no effective limit on a SENSITIVE action → you've got a finding, especially if it enables brute-force

The Bypass Angle

Sometimes a rate limit EXISTS but is easy to bypass — which is also a bug. Try:

• Adding headers like X-Forwarded-For with different IPs (some limits are per-IP and trust this header )
• Changing casing or adding characters to the endpoint
• Using the API directly when only the web UI is limited
• Rotating tokens/sessions
• GraphQL batching (send many operations in one request — batch 1 covered this)

Frame It Around Impact

"No rate limit on this endpoint" alone is often low value. "No rate limit on OTP verification, allowing full 2FA bypass and account takeover" is high/critical. Always connect the missing limit to what it ENABLES. That's the difference between an informational and a bounty.