How to Find Rate Limiting and Anti-Automation Bugs
Rate limiting protects endpoints from brute force, credential stuffing, OTP guessing, coupon abuse, and resource exhaustion. When it is missing or easily bypassed, attackers automate their way into accounts and abuse. OWASP tracks this under unrestricted resource consumption, and it remains a steady source of valid findings.
The challenge is proving the gap without actually attacking real accounts or degrading service.
High-value endpoints
- Login and MFA/OTP verification
- Password reset and email verification
- Coupon, referral, and gift-card redemption
- Signup and “check if email exists” endpoints
- Expensive search, export, or report generation APIs
Anywhere a limit protects security or money is worth testing.
Prove the gap safely
You do not need thousands of requests to show a missing limit:
- Send a small, controlled burst (a handful of requests) to a limited action on your own account or test data.
- Observe whether the server ever responds with throttling —
429, lockout, CAPTCHA, or backoff. - If none appears after a reasonable, low-volume test, document that the control is absent.
Keep volume low. The goal is to demonstrate the absence of a limit, not to brute-force anything.
Common bypasses to check
Even when a limit exists, it may be trivially defeated:
- Header spoofing: rotating
X-Forwarded-For/X-Real-IPresets per-IP counters - Case/format tricks: changing casing, trailing slashes, or parameter encoding
- Endpoint variants: a limited web route but an unlimited API or GraphQL equivalent
- Account/identifier rotation: limits per username but not per IP (or vice versa)
- Race windows: parallel requests slipping under a slow counter
Test each bypass with minimal, controlled requests against your own identifiers.
Impact matters more than the number
Programs care about consequence:
- Missing limit on OTP → account takeover via code guessing
- Missing limit on login → credential stuffing at scale
- Missing limit on coupons → financial abuse
- Missing limit on expensive APIs → denial of service / cost amplification
Frame the report around what the missing control enables, using your own account as the proof.
Common false positives
- A limit that exists but you tested below its threshold
- Client-side throttling only (server still unlimited — that's the bug)
- WAF/CDN limits that already block the attack
Report structure
Include the endpoint, your low-volume evidence (no throttling response), any bypass used, and the realistic attack it enables. Recommend per-account and per-IP limits, exponential backoff or lockouts, CAPTCHA on sensitive flows, and consistent limits across web/API/GraphQL variants.
Defensive checklist
- Enforce limits server-side on every sensitive action.
- Rate-limit by account, IP, and where relevant device — and combine them.
- Ignore client-controlled headers for counting.
- Apply the same limits to API and GraphQL equivalents of a route.
- Add lockouts, backoff, and CAPTCHA to auth and OTP flows.
Rate-limiting bugs reward hunters who think about automation and abuse economics. Prove the gap with a tiny, controlled test, show a bypass if one exists, and tie it to concrete impact.
Original Bugflare guide informed by OWASP API Security — unrestricted resource consumption.