Broken Rate Limit : From “Non-Issue” to Valid Vulnerability worth $$$

In this article, I’ll share a real-world authentication issue I discovered while testing a login functionality.At first glance, the application appeared to have rate limiting enabled. Requests eventually started returning blocked responses, and the security team believed the protection was working correctly.

However, after deeper testing, I discovered something important:

Even though requests were being “blocked,” it was still possible to identify the correct password among thousands of attempts.

This meant a brute-force attack was still practical.

Understanding the Issue

The target application had a login form.

Normally, authentication endpoints should implement protections such as:

• Rate limiting
• CAPTCHA
• Temporary account lockouts
• IP-based throttling
• Device fingerprinting

These protections exist to stop attackers from trying thousands of passwords against a user account.

Initial Testing

I intercepted the login request using Burp Suite and sent it to Intruder.

The process was simple:

1. Enter a valid email address
2. Intercept the login request
3. Send request to Intruder
4. Replace the password parameter with payload markers
5. Launch a password wordlist attack

During testing:

• Most responses returned HTTP 200
• The correct password returned HTTP 302

At first, this might not sound dangerous.

But here’s the problem:

The application was still processing password attempts and revealing which password was correct based on response behavior.

That completely defeats the purpose of rate limiting.

The Security Team’s Response

The security team responded saying:

• HTTP 200 did not indicate success
• Requests were supposedly being blocked internally
• The behavior was expected

And technically, they were partially correct.

The application did attempt to make blocked responses appear normal.

However, the actual vulnerability was not about HTTP status codes.

The real issue was:

I could still send thousands of password attempts and reliably detect the correct password.

Even if responses looked “blocked,” the authentication flow still behaved differently for valid credentials.

Convincing Security Team

After showing a detailed POC with 6k+ payloads and still getting the real password .The result was consistent:

• Invalid passwords → HTTP 200
• Correct password → HTTP 302 redirect

This allowed password enumeration and brute-force attacks despite the supposed protections. Then their response look like this

Key Lesson

One important lesson from this case:

Security controls should be evaluated based on effectiveness, not appearance.

A system may:

• Return generic responses
• Hide errors
• Use identical status codes

But if attackers can still automate login attempts and distinguish successful authentication attempts, the underlying problem still exists.

Bounty Time $$

They quickly resolve the issue and revert back to me with

So this is my first ever medium article, if you like it make sure to follow

If you want to connect on socials

https://www.instagram.com/bhavishthakral/