How I Bypassed a Password Reset Rate Limit on a Bug Bounty Target

When testing a web application's password reset flow, finding a standard rate limit is quite common. Usually, if you try to spam the endpoint with 10 or 20 requests using a tool like Burp Intruder, the server will block you, and no emails will drop into the inbox.

But sometimes, the backend defenses aren't as bulletproof as they initially seem.

In this quick write-up, I will share how I managed to completely bypass a password reset rate limit on a live target by manipulating the HTTP request structure, without giving away the exact secret sauce.

The Baseline Test (The Expected Block)

I started by intercepting a standard password reset request. To see if any basic rate limiting was in place, I sent the raw request over to Burp Intruder and fired off multiple sequential requests.

The server responded with 200 OK for the requests, but when I checked my mailbox, zero emails had arrived. The application was working as intended—silently filtering out or blocking automated, high-velocity requests to prevent spam.

The Bypass: Creative Manipulation

Many modern applications use specific request structures, tracking tokens, or client-side data to identify unique users and rate-limit automated traffic. I decided to see what would happen if I messed with how the server interpreted my traffic.

Instead of just spamming the endpoint normally, I analyzed how the backend was processing the request. By applying some creative manipulation to the HTTP request structure and altering how the data was presented to the server, I tested the endpoint again.

The Result

With the modified request in hand, I sent a rapid succession of requests.

This time, the backend tracking completely lost track of the traffic. It couldn't link the incoming requests to a specific automated profile or session. As a result, the rate limit failed entirely, and multiple valid password reset links successfully landed in the mailbox at the exact same time.

Takeaway for Developers

Rate limiting on sensitive endpoints (like login or password reset) should be strictly enforced. Developers should never rely solely on standard request structures or client-provided data to track request velocity. Instead, rate limiting should always be enforced on the backend using immutable identifiers that an attacker cannot easily manipulate — such as the target email address itself or a strict threshold on the originating IP address.