Missing Rate Limit Vulnerability: How to Test and Identify It

A missing rate limit vulnerability occurs when a web application fails to impose restrictions on how many times a particular action can be performed within a given timeframe. This oversight can lead to various forms of abuse, such as brute-force attacks, credential stuffing, Denial of Service (DoS), or resource exhaustion, depending on the endpoint’s functionality.

For example, if there is no rate limit on a login endpoint, an attacker can automate an unlimited number of login attempts, leading to brute force attacks.

Why It’s Important:

Rate limits prevent abuse of `APIs` or functionalities such as logins, password resets, account creation, and other resource-intensive operations. Without these limits, attackers can easily overwhelm the application, jeopardizing user accounts and consuming valuable system resources.

How to Test for Missing Rate Limit Vulnerabilities

Step 1: Identify Potential Endpoints

Look for high-risk endpoints in the web application where rate limiting should be applied. These include:

**Authentication** (Login, Password Reset, Signup)**Search functions** (API queries, database lookups)**Data submission forms** (Comment sections, post submissions)**API calls** (GET/POST requests with user-modifiable parameters)

Step 2: Send Multiple Requests

Use tools like **Burp Suite** or **OWASP ZAP** to intercept and send multiple identical requests to the targeted endpoint. Key areas to test:

**Login form:** Send multiple requests with different passwords to test for brute force.**Password reset:** Submit multiple password reset requests to check for flood vulnerabilities.**Data submission:** Spam form submissions (e.g., comments or posts) to test if submissions are being rate-limited.

Step 3: Monitor Responses

Track the server’s responses for inconsistencies. If no rate limiting is in place, you’ll likely receive consistent HTTP responses for each request.

- **No change in response codes (e.g., all 200 OK):** This is a sign of missing rate limiting.
- **Consistent behavior (like no CAPTCHA after multiple login attempts):** Indicates that protections are not applied.

Step 4: Increase Request Frequency
Simulate a high volume of requests at various speeds (e.g., 5, 10, or 50 requests per second) using

Burp Suite Intruder is the fastest and easiest way

Expected behavior: The server should return error codes like **429 Too Many Requests** or present a CAPTCHA after a certain threshold.Unexpected behavior: If the application continues responding without any throttle, it signals a missing rate limit.

Step 5: Check for Account Lockout (At least 400 request’s)
For authentication endpoints, test multiple failed login attempts. If no account lockout or CAPTCHA is triggered, the application may lack adequate rate limiting.

Step 6: Bypass Common Rate Limit Mechanisms (N/A on Bugcorwd)
Applications might use basic rate limits based on:

- IP address: Bypass by using a proxy, VPN, or Tor.
- User-Agent: Spoof the User-Agent header to see if it resets the limit.
- Session Cookies: Clear cookies or reset session values to test if you can bypass the rate limit.

If you successfully bypass any of these mechanisms, it’s a sign of weak or ineffective rate limiting.

Step 7: Report and Document
Document the following details for your report:

- Affected endpoints.
- Number of requests sent per second.
- The impact (e.g., brute-force login attempts, spam posts).
- How any weak rate limit protections were bypassed.

— — — — — — — — — — — — — — — — — — — — — — — -

Tools You Can Use

1. **Burp Suite**: For capturing and sending multiple requests via Intruder.
2. **OWASP ZAP**: To automate and track HTTP requests.
3. **cURL**: For quick command-line tests.

— — — — — — — — — — — — — — — — — — — — — — —

Connect with me