Bypassing Rate Limiting on a Password Reset Endpoint With a Single Whitespace Character

Rate limiting on auth endpoints is one of those things everyone implements and almost nobody tests properly. Most of the time it works fine against the obvious attack — same email, same requests, blocked after N attempts. But I've learned that the interesting question isn't "does rate limiting exist," it's "what exactly is it keying off of?"

I was looking at a forgot-password flow. Standard stuff — you submit your email, it sends a reset link, and there's rate limiting to stop someone from hammering the endpoint. I fired off a few requests with the same email through Burp, and sure enough, after a handful of attempts I got hit with a 429. Rate limit confirmed, working as intended.

So the next question was: what's the key here? Is it actually normalizing the email before comparing it, or is it just matching the raw string?

I sent the exact same email again, but this time added a trailing tab character — just \t stuck on the end of the JSON value. Nothing visible, nothing a user would ever type by accident, but technically a different string.

And the rate limit just… didn't apply. 202 Accepted, every time. Tried it again with \n instead — same result. I could send this thing as many times as I wanted, back to back, no throttling at all.

Now, the backend does eventually reject the malformed email internally, so no actual reset email goes out — that part's fine. But that's kind of beside the point. The rate limiter itself is what's broken. It's treating email and email\t as two completely different identities, when obviously they're the same target as far as any real attacker is concerned. You just keep appending garbage characters and get infinite fresh "identities" to throw at the endpoint.

That's a bigger deal than it sounds like at first. Password reset endpoints are exactly the kind of unauthenticated, internet-facing surface you want tightly controlled — this bypass opens the door to unlimited requests against it, which stacks into a few different risks: anti-automation controls become meaningless, you've got a decent DoS/log-flooding vector against whatever's processing these requests internally, and if the endpoint's responses differ even slightly based on whether an email exists in the system, you've now got an amplified user enumeration path too — since nothing's stopping you from testing thousands of variations rapidly.