[Free link]

Rate limiting is one of those security controls that everyone is familiar with, yet it often fails in real-world applications. For security researchers and bug bounty hunters, weak or missing rate limits are low-hanging fruit. For developers, they are usually the silent reason behind account takeovers, OTP abuse, and infrastructure abuse.

This post focuses on where to look for rate-limiting issues and practical techniques attackers use to bypass them, so you can either exploit them responsibly or fix them before someone else does.

Common Places Where Rate Limiting Fails

Most applications apply rate limiting inconsistently. Some endpoints are protected, others are forgotten. These are the first places you should always test:

• Login and signup flows
• Password reset endpoints
• OTP / 2FA verification and resend APIs
• Messaging systems, forums, comments, and pin codes
• Coupon codes, promo code validation, and referrals
• "Contact us" or feedback forms (often ignored, often abused)

If an endpoint triggers an email, SMS, or database write, it deserves rate limiting. Unfortunately, many don't get it.

Bypassing Rate Limits by Playing With Parameters

A surprisingly common mistake is applying rate limits only to specific endpoint names. If /signup is protected, but /SignUp or /sign-up is not, you already have a bypass.

Try changing casing, formatting, or naming variations, for example:

sign-up  
Sign-up  
SignUp

This works more often than it should, especially in poorly normalized backend routing.

Abusing IP-Based Rate Limiting With Headers

Most applications rely on headers like X-Forwarded-For to identify the client's IP address. This is dangerous if the backend trusts these headers blindly.

Attackers often test multiple IP-related headers or even send the same header twice to confuse the backend:

X-Forwarded-For: 127.0.0.1
X-Forwarded-For: 8.8.8.8

Other headers worth testing include:

X-Forwarded: 127.0.0.1
X-Forwarded-By: 127.0.0.1
X-Forwarded-For-Original: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Client-IP: 127.0.0.1
X-True-Ip: 127.0.0.1
Forwarded: 127.0.0.1

A simple twist: brute-force the IP itself, for example 127.0.0.1, 127.0.0.2, 127.0.0.3. If the rate limit is IP-based and poorly implemented, this can be enough.

Here's my blog post on how I did it.

OTP and SMS Rate Limit Bypass Tricks

OTP endpoints are a goldmine. Many applications validate the format of a phone number differently across endpoints.

A practical test:

1. Capture the OTP request.
2. Remove the country code (+91) entirely.
3. Re-add it in a different format.

Example:

• From: +91xxxxxxxxxx
• To: xxxxxxxxxx
• Or: +91 xxxxxxxxxx

If the backend treats these as different identities, rate limits reset.

Null Bytes, CRLF, and Whitespace Injection

Some rate-limit checks fail when unexpected characters are introduced. Try injecting encoding edge cases into parameters or endpoints:

%00, %0d%0a, %09, %0c, %20, %2e, '/', %0d

These tricks can confuse parsing logic, routing layers, or WAF rules — especially in legacy systems.

Rotating User Agents, Cookies, and IPs

Basic, but still effective. Some systems track limits per session, per cookie, or per user agent.

Changing:

• User-Agent
• Session cookies
• Authorization headers

…can reset limits if enforcement is shallow.

For IP rotation, tools like Burp extensions that route traffic via AWS API Gateway or Tor can be very effective. Each request appears to come from a new region, bypassing simple IP-based controls.

A good technical reference:

• Rhino Security Labs on AWS IP-based blocking

CAPTCHA Isn't Always the Final Boss

CAPTCHA is often bolted on as a quick fix — and that's exactly why it fails.

Try:

1. Removing the CAPTCHA parameter entirely.
2. Replace it with random data of the same length.
3. Sending the request to Intruder with interception enabled.

In some cases, the CAPTCHA is only validated on the frontend or skipped under certain conditions. Automation wins.

HTTP Method Confusion

Rate limits are often applied only to specific HTTP methods.

If an endpoint usesGET, try:

• POST
• PUT
• PATCH
• HEAD (especially effective in APIs)

HEAD Requests are frequently overlooked and sometimes processed without proper checks.

The Forgotten "Contact Us" Endpoint

Many applications aggressively protect login but completely ignore contact or feedback forms. If these trigger emails or ticket creation, lack of rate limiting can lead to spam, denial of service, or cost exhaustion.

Search functionality, export features, and report generation can all be computationally expensive. If they're not rate-limited, they're vulnerable to abuse that can impact your infrastructure and other users.

Always test them.

Extra Slashes, Same Endpoint

Some routing systems treat these as different paths:

//sendEmailTicket
///sendEmailTicket
////sendEmailTicket

If rate limiting is applied per-path string instead of normalized routing, this trick can bypass it entirely.

Final Thoughts

Rate limiting is not about adding a single middleware and calling it a day. It needs:

• Consistent enforcement across endpoints
• Proper IP handling
• Normalized routing
• Server-side validation (not frontend trust)

For security researchers and bug bounty hunters, rate limit bypasses are reliable findings. They're present in applications of all sizes, they're straightforward to test for, and they have a clear security impact. For developers and security teams, these vulnerabilities represent real risk. Account takeovers, OTP brute-forcing, resource exhaustion, and cost inflation all stem from rate-limiting failures. They're preventable, but only if you understand how they're exploited.