Rate Limiting Bug Bounty 2026 — Find & Bypass Rate Limits

✨ AI Summary

This educational article from a bug bounty mastery course teaches hunters how to identify, test, and exploit rate limiting vulnerabilities across authentication endpoints. It explains why rate limiting flaws are dangerously underestimated by bug bounty researchers, demonstrates concrete testing methodology using Burp Intruder and Turbo Intruder, and provides specific techniques to bypass IP-based rate limiters. The article matters because properly communicated rate limit findings with feasibility calculations earn significantly higher severity ratings and payouts than generic 'missing rate limit' reports.

Key insights

OTP endpoints: 83-minute account takeoverA 6-digit numeric OTP has exactly 1,000,000 possible values. Without rate limiting, an attacker receiving an OTP request on a victim's behalf can enumerate all codes at 100 requests per second, finding the correct code in approximately 2 hours 46 minutes on average. The article emphasizes this is not a Medium finding but Critical because it enables complete account takeover, demonstrating why severity hinges on feasibility calculation rather than the vulnerability existing in isolation.
Null payload testing detects missing limitsThe detection methodology involves capturing a target request in Burp Intruder, marking a credential field as payload position, generating 100 null payloads (which sends the same request 100 times), and observing response status codes. If all 100 requests return 200 with identical response length and no 429 status or lockout message appears, the endpoint has no rate limiting. This technique works because it measures whether the application changes its behavior under repeated requests, not whether specific payloads succeed.
X-Forwarded-For header spoofing bypasses IP limitsMany applications implement IP-based rate limiting using request headers rather than network-layer source IPs, making the limits trivially bypassable. By adding or rotating the X-Forwarded-For header (or alternative headers like X-Real-IP, X-Client-IP, CF-Connecting-IP) in Burp Intruder payloads, each request appears to come from a different source IP, resetting the rate limit counter for each fake IP. The article identifies this as the most commonly successful bypass technique because it exploits a fundamental implementation flaw.
Seven endpoint categories require priority testingThe article ranks endpoints by rate limit risk: OTP/2FA verification (highest priority), login forms, password reset (both token request and verification), account registration, API authentication endpoints, contact/messaging features, and search/data enumeration endpoints. For each category, the article provides specific testing instructions—for example, testing OTP by sending 50 requests with different code values and watching for 429 responses or lockout messages, or testing password reset by submitting 50 reset requests for one email address.
Impact calculation drives severity ratingThe article emphasizes that generic 'rate limiting is missing' reports receive Low severity, while specific calculations earn High or Critical ratings. The formula is: (keyspace size / requests per second) / 2 = average time to success. For a 4-digit PIN: 10,000 ÷ 100 req/s ÷ 2 = 50 seconds. The article states that including explicit, quantified time-to-success numbers 'is what earns the higher severity rating' and provides a real example where a 4-digit banking PIN bypass was rated Critical because the calculation showed 50-second account takeover feasibility.
Turbo Intruder enables high-speed practical PoCsBurp Community Edition's Intruder is rate-limited to one request per second, sufficient for detection but too slow to demonstrate real attack feasibility in a proof-of-concept. Turbo Intruder is a free Burp extension that sends requests at HTTP/2 pipeline speeds—hundreds to thousands per second. The article provides a basic Turbo Intruder script that queues 100 requests with sequentially generated payloads, allowing hunters to demonstrate that 1,000,000 OTP codes can actually be enumerated within the calculated timeframe.
Testing methodology chains with authentication bypassThe article positions rate limiting within a larger authentication attack chain, noting that Day 15 covered business logic flaws and Day 17 will cover JWT attacks. Rate limiting vulnerabilities are most critical when combined with other weaknesses—the article explicitly states 'the value of rate limit testing multiplies dramatically once you combine it with other vulnerabilities,' establishing that rate limit findings on their own have lower impact but enable higher-severity chains when chained with business logic flaws or token vulnerabilities.
Manual observation precedes automated testingExercise 1 instructs hunters to observe rate limit indicators manually before opening Burp: checking DevTools Network tab for 429 status codes, Retry-After headers, X-RateLimit-* headers, CAPTCHA appearance, or account lockout messages after multiple failures. The article states 'most rate limit vulnerabilities are visible through manual observation before you open Burp,' meaning an OTP flow that never changes error messages or locks after 10 manual attempts is almost certainly unbounded and worth automated testing.

Bottom line: Rate limiting vulnerabilities are systematically underestimated as Low severity by bug bounty hunters, but when properly tested for bypass techniques and reported with specific feasibility calculations—such as '1,000,000 OTP codes enumerable in 83 minutes at 100 req/s enabling account takeover'—they consistently earn Critical and High severity ratings. The key differentiator is combining concrete attack numbers with practical demonstration using tools like Burp Intruder and Turbo Intruder to sho

🎯 BUG BOUNTY COURSE
FREE

Part of the 60-Day Bug Bounty Mastery Course

Day 16 of 60 · 26.7% complete

⚠️ 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

What Rate Limiting Vulnerabilities Are and Why They Enable Account Takeover
The 7 Endpoint Types You Must Test for Missing Rate Limits
Detection Methodology — Null Payload Testing With Burp Intruder
Rate Limit Bypass Techniques — X-Forwarded-For and Header Manipulation
Turbo Intruder — High-Speed Parallel Attacks for Rate Limit Testing
Calculating Real Attack Feasibility for Your Bug Bounty Report

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.

securityelites.com

Rate Limiting Vulnerability — Attack Feasibility Calculator

6-digit OTP

1,000,000 possible codes

~2.7 hrs @ 100 req/s

4-digit PIN

10,000 possible codes

~1.6 min @ 100 req/s

Password (top 100)

100 attempts needed

~1 sec @ 100 req/s

Password reset token

Depends on token length

Varies by entropy

📸 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

RATE LIMIT DETECTION — BURP INTRUDER NULL PAYLOAD METHOD

# Step 1: Capture target request in Burp (e.g. login POST)

# Step 2: Right-click → Send to Intruder

# Step 3: Positions tab → Clear all positions → Add § on password value

username=admin&password=§test§

# Step 4: Payloads tab → Payload type: Null payloads

Payload type: Null payloads

Generate: 100 payloads

# This sends the same request 100 times with the same password

# Step 5: Options → Uncheck “Follow redirects” for cleaner results

# 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.

RATE LIMIT BYPASS TECHNIQUES — HEADER MANIPULATION

# Technique 1: X-Forwarded-For header spoofing

# Add to request — many apps use this for real client IP detection

X-Forwarded-For: 1.2.3.4

# In Burp Intruder — add X-Forwarded-For as a second payload position

username=admin&password=§test§

X-Forwarded-For: §1.2.3.§4

# Technique 2: Alternative IP headers

X-Real-IP: 5.6.7.8

X-Remote-IP: 9.10.11.12

X-Client-IP: 13.14.15.16

CF-Connecting-IP: 17.18.19.20

# Technique 3: Null byte / case variation in username

username=admin%00 # null byte creates different rate limit key

username=Admin # case variation may reset counter

username=admin+ # space variation

# Technique 4: Add random unused parameter to vary request signature

username=admin&password=test&cache_buster=§RANDOM§

🌐 EXERCISE 2 — PORTSWIGGER (20 MIN)

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

# Install Turbo Intruder in Burp Suite

# Extender → BApp Store → search “Turbo Intruder” → Install

# 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

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

username=admin%00Null byte bypass — creates unique rate limit key per variation

Turbo Intruder — concurrentConnections=5High-speed testing beyond Community Edition Intruder rate limit

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

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.
OWASP API Security — Unrestricted Resource Consumption — The OWASP API Security Top 10 entry for rate limiting vulnerabilities in API contexts, with real-world examples and defensive implementation guidance.

Mr Elite

Owner, SecurityElites.com

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.