⚠️ Authorised Testing Only: Rate limit testing involves sending large volumes of automated requests to application endpoints. Only perform this testing against systems within an explicit bug bounty programme scope or applications you own. Sending automated requests to systems without authorisation may violate terms of service and applicable law.
Rate limiting bug bounty 2026 is one of the most underreported vulnerability classes in bug bounty — not because it is rare, but because hunters see it, think “low severity” and move on without testing the bypass techniques that turn a Medium finding into a Critical account takeover chain. An OTP verification endpoint with no rate limit is not a Medium finding. It is a 6-digit code, 1,000,000 possible values, and a Burp Intruder attack running at 100 requests per second. That is a 3-hour automated account takeover. Today you are learning to think about it correctly.
🎯 What You’ll Master in Day 16
Identify every endpoint that should have rate limiting in a typical application
Test for missing rate limits using Burp Intruder with Null payloads
Apply the top 6 rate limit bypass techniques against IP-based limiters
Use Turbo Intruder for high-speed parallel request attacks
Calculate and communicate real attack feasibility in your bug bounty report
⏱️ 50 min read · 3 hands-on exercises
📊 Have you tested for rate limiting before?
✅ The value of rate limit testing multiplies dramatically once you combine it with other vulnerabilities. This guide covers both the detection methodology and the bypass techniques that unlock higher-severity chains in programmes that have partial rate limiting implemented.
📋 What You’ll Master — Rate Limiting Bug Bounty 2026
In Day 15 we exploited business logic flaws in application workflows. Rate limiting is a specific type of business logic control — one that governs how frequently operations are allowed rather than whether the sequence is correct. Missing rate limits are listed in the OWASP API Security Top 10 as API4:2023 (Unrestricted Resource Consumption). The 60-Day Bug Bounty Mastery Course covers it Day 16 because it chains directly with authentication vulnerabilities in the days ahead.
What Rate Limiting Vulnerabilities Are and Why They Enable Account Takeover
Rate limiting is a control that restricts how many requests a client can make to an endpoint within a time window. Implemented correctly, it prevents brute force attacks, OTP enumeration, credential stuffing, and resource exhaustion. Missing or bypassable rate limiting makes every authentication endpoint exploitable by automation.
The most dangerous missing rate limit scenario is OTP verification. A 6-digit numeric OTP has exactly 1,000,000 possible values. If the application does not rate limit the verification endpoint, an attacker with a victim’s phone number can receive an OTP request on their behalf, then enumerate all 1,000,000 possible codes against the verification endpoint. At a conservative 100 requests per second, the correct code is found within 2 hours and 46 minutes on average.
📸 Rate limit attack feasibility — missing rate limits on OTP and PIN endpoints make brute-force attacks practical at modest request rates. These numbers belong in your bug bounty report.
The 7 Endpoint Types You Must Test for Missing Rate Limits
Not every endpoint needs aggressive rate limiting. The endpoints that do are those where automation enables authentication attacks. Test these seven categories on every target, in this order of priority:
1. OTP / 2FA Verification: The highest-value rate limit target. If an application sends a numeric code and verifies it via an API endpoint, that endpoint must rate limit aggressively — typically 5–10 attempts before lockout. Test by sending 50 requests with different code values and watching for 429 or lockout.
2. Login Endpoints: Classic brute force target. Send 100 requests with different passwords — no account lockout or 429 after 10+ failed attempts is a finding. Note that some programmes exclude this if the application has CAPTCHA — test the CAPTCHA separately.
3. Password Reset: Both the token request endpoint (can be abused to spam victims) and the token verification endpoint (brute-forceable if tokens are short). Send 50 password reset requests for one email address — application should limit this to prevent user harassment.
4. Account Registration: Missing rate limits here enable mass account creation, which feeds credential stuffing infrastructure and platform abuse. Less critical for direct account takeover but High severity for fraud programmes.
5. API Authentication: API key verification, OAuth token endpoints, and service-to-service authentication flows. Often implemented with less rate limiting than web UI flows.
6. Contact / Messaging Features: If the application can send emails or SMS via user action, missing rate limits enable SMS bombing and email spam abuse at the victim’s expense.
7. Search and Data Endpoints: Missing rate limits here enable mass data enumeration — particularly dangerous when combined with IDOR findings where sequential IDs can be iterated.
🛠️ EXERCISE 1 — BROWSER (10 MIN · NO INSTALL)
Identify Rate-Limited Endpoints on a Real Bug Bounty Target
⏱️ Time: 10 minutes · Browser and DevTools only
Step 1: Choose a target from a public bug bounty programme
(one with a login, OTP, or password reset feature)
Step 2: Open DevTools (F12) → Network tab
Step 3: Navigate to the login page and attempt 5 wrong password logins
Observe: does the response change after multiple failures?
Look for: 429 status, Retry-After header, CAPTCHA appearing,
or account lockout message
Step 4: Navigate to the password reset page (if it exists)
Observe: is there a CAPTCHA or any visible throttling?
Submit 3 password reset requests for the same email — does
anything change on request 2 or 3?
Step 5: In DevTools Network tab, look for any response headers:
X-RateLimit-Limit
X-RateLimit-Remaining
X-RateLimit-Reset
Retry-After
These indicate rate limiting is implemented — note the limit values
Step 6: If you find an OTP or 2FA flow — attempt 10 wrong codes manually
Does the application lock you out? Show a different message?
Or just keep saying “invalid code” indefinitely?
Do NOT automate anything in this exercise — manual observation only.
✅ What you just learned: Most rate limit vulnerabilities are visible through manual observation before you open Burp. An OTP flow that never changes its error message or locks the account after 10 manual failures is almost certainly unbounded. A login form with no CAPTCHA and no lockout after 5 failures is a rate limit test candidate. The presence of X-RateLimit headers tells you rate limiting exists — the absence of those headers and any visible throttling after manual failures tells you it likely does not.
📸 Screenshot any rate limit headers found in DevTools and share in #day-16-ratelimit on Discord.
Detection Methodology — Null Payload Testing With Burp Intruder
# Step 6: Start Attack — watch Status and Length columns
# Result interpretation:
All 100 return 200 with same length → NO RATE LIMITING
Response changes to 429 after N requests → Rate limit at N req/window
Account lockout message after N requests → Lockout-based protection
# For OTP testing — use Sequential numbers payload type:
Payload type: Numbers
From: 000000 To: 000100 Step: 1
# Tests first 100 OTP codes — if none trigger 429 → no rate limit
Rate Limit Bypass Techniques — X-Forwarded-For and Header Manipulation
If a rate limit is detected, the next step is bypass testing. Many rate limiters are implemented at the IP address level — tracking requests per source IP. These are trivially bypassed by manipulating headers that the application uses to determine the client’s IP, or by rotating through IP addresses.
Exploit Missing Rate Limiting on a Login Form — PortSwigger Lab
⏱️ Time: 20 minutes · Free PortSwigger Web Security Academy account
Step 1: Go to portswigger.net/web-security/authentication/password-based
Step 2: Open: “Username enumeration via different responses” OR
“Broken brute-force protection, multiple credentials per request”
Step 3: The lab has a login form with limited protection
Use Burp Intruder to test the rate limit:
— Capture the login POST request
— Send to Intruder → mark password as payload position
— Payload type: Null payloads → 50 requests
— Start Attack → observe status codes
Step 4: Note at what request number (if any) the response changes
to indicate rate limiting or lockout
Step 5: If rate limit is detected, try the X-Forwarded-For bypass:
Add X-Forwarded-For: §1.2.3.§4 as a second payload position
Set up a pitchfork attack with incrementing IP addresses
Step 6: Document:
— Does the application rate limit? At what threshold?
— Did any bypass technique work?
— What severity would you assign this finding?
✅ What you just learned: PortSwigger’s authentication labs provide the safest environment to practice Intruder-based rate limit testing before trying it in real programmes. The X-Forwarded-For bypass is the most commonly successful technique against web application rate limiters because many developers implement IP-based limiting using request headers rather than network-layer source IPs — a design choice that makes the limit trivially bypassable from any client.
📸 Screenshot the Intruder results showing successful bypass and share in #day-16-ratelimit on Discord.
Turbo Intruder — High-Speed Parallel Attacks for Rate Limit Testing
Burp Suite Community Edition’s Intruder is rate-limited to one request per second — fast enough to test whether rate limiting exists, but too slow to demonstrate real attack feasibility in a PoC. Turbo Intruder is a free Burp extension that bypasses this limitation, sending requests at true HTTP/2 pipeline speeds — hundreds to thousands per second.
TURBO INTRUDER — INSTALL AND BASIC RATE LIMIT TEST
# Usage: Right-click any request → Extensions → Turbo Intruder
# Basic no-rate-limit detection script:
def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=100)
for i in range(100):
engine.queue(target.req, str(i).zfill(6))
# %s in request body = placeholder for payload
# Example: password=%s or otp_code=%s in captured request
# This queues 100 requests with values 000000-000099
# Watch results window — filter for non-standard responses
⚡ EXERCISE 3 — KALI TERMINAL (20 MIN)
Test DVWA Login Rate Limiting at All Security Levels Using Burp Intruder
⏱️ Time: 20 minutes · DVWA running, Burp Suite configured
DVWA LOGIN RATE LIMIT TEST — BURP INTRUDER
# Step 1: Navigate to DVWA login (Low security)
http://127.0.0.1/dvwa/login.php
# Step 2: Capture login POST in Burp, send to Intruder
# Step 3: Mark password field as payload position
username=admin&password=§test§&Login=Login
# Step 4: Payloads → Null payloads → Generate 50
# Step 5: Start Attack — note all responses
All 50 return 200 — DVWA has NO rate limiting on login
# Step 6: Now switch to password wordlist payload
# Payloads → Simple list → paste these common passwords:
password
admin
123456
password123
letmein
# Step 7: Start Attack — sort by Length
Response length for “password” = longer (login success)
# This demonstrates the full brute-force impact of missing rate limit
# Write up: “DVWA login endpoint has no rate limiting.
# 50 requests tested, no 429 or lockout observed.
# Top-100 password list would identify valid credentials in <2 seconds.”
✅ What you just learned: The DVWA exercise demonstrates the complete rate limit testing workflow in a safe lab environment: detect (Null payloads), confirm (no 429 in 50 requests), and demonstrate impact (wordlist attack succeeds with no blocking). The impact sentence at the end — specific, quantified, timed — is exactly what belongs in a bug bounty report. “No rate limiting” alone gets rated Low. “50 requests with no throttling, top-100 password list identifies valid credentials in under 2 seconds” gets rated High.
📸 Screenshot Intruder results showing all 200 responses with no 429 and share in #day-16-ratelimit on Discord. Tag #ratelimit2026
Calculating Real Attack Feasibility for Your Bug Bounty Report
The difference between a Low payout and a High payout for a rate limit finding is almost entirely in how you communicate impact. The calculation is simple: (keyspace size / requests per second) / 2 = average time to success. Include this calculation explicitly in your report.
For a 6-digit OTP with no rate limit: 1,000,000 ÷ 100 req/s ÷ 2 = 5,000 seconds average = 83 minutes. That is a concrete, specific, alarming number that a programme manager understands immediately. For a 4-digit PIN: 10,000 ÷ 100 ÷ 2 = 50 seconds. For a login form against a top-1000 password list: 1,000 ÷ 100 ÷ 2 = 5 seconds. The specificity of these numbers — not “rate limiting is missing” but “account takeover achievable in 83 minutes” — is what earns the higher severity rating.
🧠 QUICK CHECK — Day 16
You test a 6-digit SMS OTP verification endpoint. You send 200 requests with different OTP values and receive 200 responses with status 200 and the message “Invalid code”. No 429, no lockout. What is the correct severity for this finding and why?
📋 Rate Limit Testing Checklist — Day 16
OTP / 2FA verification endpointHighest priority — 6-digit OTP brute-forceable in 83 min with no limit
Login form — Null payload × 50Test without valid credentials — no 429 = missing rate limit finding
Password reset request endpointTest for SMS/email spam abuse — 50 reset requests for same email
X-Forwarded-For: 1.2.3.§N§Primary bypass technique — rotate fake source IP in header
Impact: keyspace / req_per_sec / 2Calculate and include average time-to-success in every report
🏆 Mark Day 16 as Complete
Rate limiting vulnerabilities are in more applications than most hunters test for. The OTP bypass chain you learned today — no rate limit + 6-digit code + 83-minute brute force — is a Critical finding that appears in real programmes regularly. You now know how to find it, bypass protections, and report it at the right severity.
❓ Frequently Asked Questions
What is a rate limiting vulnerability?
A rate limiting vulnerability exists when an application fails to restrict how frequently a client can make requests to a sensitive endpoint. Without rate limiting, automated attacks can brute force login forms, enumerate OTP codes, spam password resets, and abuse API endpoints. OWASP classifies missing rate limiting as a Security Misconfiguration and API4 Unrestricted Resource Consumption.
What HTTP status code indicates a rate limit?
HTTP 429 Too Many Requests is the standard status for rate limiting, defined in RFC 6585. Applications may also use 503. A properly implemented rate limit returns 429 with a Retry-After header after the threshold is exceeded. In Burp Intruder, the absence of any 429 across 100+ requests confirms missing rate limiting.
What are the most common rate limit bypass techniques?
The most effective techniques: X-Forwarded-For header rotation (fakes source IP to IP-based limiters), alternative IP headers (X-Real-IP, X-Client-IP, CF-Connecting-IP), null byte injection in username (%00 creates unique rate limit key), case variation, and parameter pollution. Test them in order when a rate limit is detected.
Is missing rate limiting always a valid bug bounty finding?
Not always. Missing rate limits on non-sensitive public APIs are typically out of scope or Low. Missing rate limits on login, OTP verification, password reset, or authentication flows are almost universally accepted as Medium to Critical. The key is demonstrating practical attack feasibility — calculate and include the time-to-success in your report.
What is the difference between missing rate limiting and CAPTCHA bypass?
Missing rate limiting means no server-side request frequency restriction. CAPTCHA is a separate anti-automation control. Both protect against automated attacks through different mechanisms. CAPTCHA can often be bypassed — missing rate limiting is the critical backend failsafe. A complete defence requires both.
What comes after rate limiting in the Bug Bounty course?
Day 17 covers JWT Attacks — weak signing algorithms, None algorithm bypass, algorithm confusion, and key injection in authentication tokens. JWT vulnerabilities chain naturally with rate limiting findings: bypass the rate limit, then exploit the JWT to achieve complete authentication bypass.
← Previous
Day 15: Business Logic Vulnerabilities 2026
Next →
Day 17: JWT Attacks Bug Bounty 2026
📚 Further Reading
Business Logic Vulnerabilities 2026— Day 15 covers workflow bypass and price manipulation — the logic flaw category that combines with rate limiting to create high-severity authentication attack chains.
Burp Suite Setup for Bug Bounty— Day 2 covers Burp Suite configuration including Intruder setup, payload types, and Turbo Intruder installation — the tools used for all rate limit testing.
60-Day Bug Bounty Mastery Course— The complete course hub from beginner recon through advanced vulnerability chaining including the authentication attack days that build on rate limiting.
PortSwigger Authentication Labs— Official PortSwigger Web Academy authentication vulnerability track — 14 labs covering brute force, broken authentication, and multi-factor authentication bypass techniques.
The rate limit finding that earned the biggest payout I have ever seen on a single endpoint was a 4-digit PIN on a banking application’s account recovery flow. The PIN was sent via SMS, the verification endpoint had absolutely no rate limiting, and the account recovery flow did not require the original device or email confirmation — just the PIN. At 100 requests per second: 10,000 possible codes, average 50 seconds to enumerate. I ran the Null payload test, saw zero 429 responses across 200 requests, calculated the feasibility, and filed the report in 20 minutes. The programme paid Critical. The calculation — “10,000 codes ÷ 100 req/s = 100 seconds maximum, 50 seconds on average, enabling complete account takeover of any user who has initiated an account recovery” — was the entire justification for the Critical rating. Numbers do the arguing for you.
Leave a Reply