BOOK THIS SPACE FOR AD
ARTICLE ADRate limiting is a common security control used by developers to prevent abuse, brute-force attacks, and API misuse. However, misconfigurations where no rate limit is implemented can lead to serious vulnerabilities, allowing attackers to perform account takeovers, scrape data, or exploit business logic flaws.
For bug bounty hunters, no rate limit vulnerabilities are some of the easiest and most rewarding bugs to find.
When applications fail to enforce rate limiting, attackers can send unlimited requests without any restrictions. This is commonly found in:
Login Forms (leading to brute-force attacks)Password Reset & Account Recovery2FA & OTP ValidationAPI Endpoints (leading to mass data extraction)Sensitive Actions (such as money transfers, coupon redemption, etc.)LETS DIVE INTO IT UwU
We will be finding no rate limit vulnerability and in order to do so we need a target and in my case ill be showcasing no rate limit vulnerability i found on my client web portal on send otp funtionality however generally you will need a target and burp suite to test no rate limit.
CASE SCENERIO:
The website was sending a request for generating and sending OTP. We captured that request and it had a account number parameter, we will be using that to test no rate limit.
STEPS:
Fire up burp suite
setup proxy to capture traffic
identify target such as login functionality, reset password or send otp functionality. In our case its OTP functionality.
send the request, for example: send otp or login using random credentials etc.
capture the request
send the request to intruder and identify the parameter for payload position
Here we are using account number parameter and adding our payload position in the end of payload.
We will select payload type to null payload so that it does not add anything in parameter value except for null values ( nothing ). We are doing so to send unlimited OTP that will lead to
Resource ExhaustionFlood users emails and text messages with OTPsNext we are going to verify if its vulnerable and does not have rate limitting. Start the attack and observe
As we can see over here that all the requests are going through and giving a response code 200 and in response there is a success parameter value too pointing that otp was successfully sent. This proves that vulnerability exists.