Return to training

Rate Limits.. can we bypass them? Shared by @zseano - Updated on 28/09/2018




I don't think rate limits need an explanation, but for those scratching their head: Rate limits are designed to stop you from abusing a certain action/endpoint, for example logging in (brute forcing an account). When a rate limit occurs the user is sometimes either blocked from performing that action for x time, or they are hit with captcha.

In this tutorial we're going to go over some bypasses i've used in the past on bounty programs and places you can look.

Please read: Rate limits are often argued about bugs. Things like spamming is sometimes not considered a "security bug", so please use your head when looking and reporting these types of bugs.


First of all i'm going to outline common actions which should be protected by rate limiting, and places you can maybe score a bounty.

  • Login
  • The most obvious. If there is no rate limiting on login then you can easily brute force accounts with ease.

  • Reset Password
  • Not exactly a HUGE security flaw (so don't expect a bounty), but spamming a users' email with forgotten passwords links could get annoying. I've had bugs like this accepted before.

  • 2Factor Login
  • Even if you know someones login credentials, if 2FA is enabled chances are you won't get any further. Yay. Sometimes the 2FA text/email/call you receive will be a 4-6 digit number and if no rate limiting applies here, what can we do? You guessed it, brute the code.

  • Enumerating users information
  • So this one will require a bit of explaining as it isn't as simple as that, and I don't want people think you can spam programs with meaningless bugs. Let's imagine we've found an IDOR< on this site and we can literally ping /api/?id=0-100000 and pull all their users data (incrementing 0 up to 100000). In my opinion, an API which returns a users private information should have rate limiting on it. (By private I mean things like email, phone number etc). Not only does this bug you just found have IDOR, but you can impress them more and advise them "Hey.. perhaps you should also rate limit this?"

  • Sign up
  • This all depends on the site and what actions a member can do. If for example it is a site which contains a voting system and you can manipulate this mass signing up & voting, signup should require rate limiting. A lot of programs say "spam" is out of scope, but this is where you begin chaining bugs:

    - Find rate limit bypass on signup.
    - Find rate limit bypass on sending messages to other users.
    - Find bypass for link bans in messages.

    Notice how we chained a ton of bugs to essentially cause a huge problem? If rate limiting existed on signup the impact would of been less.

Methods to bypass

Rate limits are fun to find and even more fun to chain together to create something with a huge impact. Here are some methods I use to bypass rate limits:

  • %00, %0d%0a, %09, %0C, %20, %0
  • Notice the screenshot at the top? I first reported that %00 bypassed a certain endpoint, and when they replied fix I simply tried %0d and the rate limit was again bypassed. As pointed out in my recent tweet, using things like null byte and CRLF can sometimes be perceived as spaces, therfore leading to a potential rate limit bypass. An example is when logging in: let's imagine a site has rate limit on logging in, but the rate limit applies to the account. So if we try to login to [email protected]x time, but you're not locked from trying [email protected]. A good bypass is to use [email protected]%00 and see if that bypasses. Make sure when testing this bug you verify that logging into your OWN account with %00 on the end actually works.

  • Changing cookies
  • I've seen some interesting cases in which a site will rate limit you based on your session. For this method I will sometimes change the session cookie to be anything and see if it accepts it, or i'll work out a way to re-generate a new session with ease.

  • Changing IP
  • Of course the most common. An amazing read is over here by @arneswinnen on HackerOne: https://hackerone.com/reports/127844. He explains everything perfectly.

  • Changing account
  • Pretty simple but if an action on a website only allows your account to perform it x times, can you bypass this limit by mass changing account? With this think about the bug in hand. If you can manipulate important data, or you can gain access to something private then it is something i'd report.

  • Mobile sites/apps
  • In my experience most mobile apps and sites are vulnerable to rate limiting bypass purely because they don't have any. I'm not sure why devs forget rate limiting their mobile endpoints.. but if you're a mobile dev tweet me and let me know ;)

Think before reporting

As explained a few times in this post, think before reporting. Rate limiting doesn't have to exist on EVERY action/endpoint, so make sure the rate limiting bypass you've found has an actual security impact. If you can brute force accounts, manipulate important data, harvest private data, or chain a few bugs to unleash mass spam across a site, then get it reported. (I've probably missed some common actions, so please use your head.

Happy hunting!