Bypass Rate Limiting Controls with Burp Suite (2026)

Burp Suite can bypass rate limiting controls by rapidly sending requests that exceed the server’s capacity to track or enforce limits on a per-request basis.

Let’s see this in action. Imagine a simple API endpoint, /api/login, that’s supposed to allow only 10 login attempts per minute per IP address.

Here’s a simulated scenario:

from flask import Flask, request, jsonify
import time

app = Flask(__name__)
login_attempts = {}  # {ip_address: [(timestamp, success_status), ...]}
RATE_LIMIT_PER_MINUTE = 10
TIME_WINDOW_SECONDS = 60

@app.route('/api/login', methods=['POST'])
def login():
    ip_address = request.remote_addr
    current_time = time.time()

    if ip_address not in login_attempts:
        login_attempts[ip_address] = []

    # Remove old attempts outside the time window
    login_attempts[ip_address] = [
        (ts, status) for ts, status in login_attempts[ip_address]
        if current_time - ts < TIME_WINDOW_SECONDS
    ]

    if len(login_attempts[ip_address]) >= RATE_LIMIT_PER_MINUTE:
        return jsonify({"message": "Rate limit exceeded. Try again later."}), 429

    # Simulate login attempt
    username = request.json.get('username')
    password = request.json.get('password')
    success = (username == "admin" and password == "password123")

    login_attempts[ip_address].append((current_time, success))

    if success:
        return jsonify({"message": "Login successful"}), 200
    else:
        return jsonify({"message": "Invalid credentials"}), 401

if __name__ == '__main__':
    app.run(debug=True)

This Flask app tracks login attempts by IP. If an IP makes more than 10 requests within a 60-second window, it gets a 429 Too Many Requests response.

Now, how would Burp Suite tackle this? The core idea is to overwhelm the rate limiter’s tracking mechanism rather than its enforcement mechanism. Many rate limiters are designed to track requests sequentially. If you can send requests faster than the limiter can record and process them, you can slip through.

Burp Suite’s "Intruder" tool is perfect for this. You can configure it to send a large number of requests very quickly.

1. Target Setup: Point Burp Suite at your /api/login endpoint.
2. Intruder Configuration:
   • Go to the "Intruder" tab.
   • Select "Positions".
   • Add the request to the Intruder.
   • Mark the "password" field (or any other variable part of the request) as a payload position.
   • Select "Sniper" attack type (usually fine for this).
3. Payloads:
   • Go to the "Payloads" tab.
   • Under "Payload Sets", choose "Simple list".
   • For "Payload Options", select "Numbers" and set the range to start from 1 and end at, say, 1000. This will try 1000 different (likely invalid) passwords.
   • Crucially, under "Grep - Match", you can add patterns to filter results. You might look for 200 OK responses (successful logins, though unlikely here) or 401 Unauthorized. You’d want to ignore the 429 Too Many Requests responses.
4. Speed Configuration: This is key.
   • Go to the "Options" tab.
   • Scroll down to "Resource pool". Select "Create new resource pool".
   • Set "Number of threads" to a high number, e.g., 200.
   • Set "Delay between requests" to 0.
   • Alternatively, if you want to be more precise and avoid overwhelming your own network or the target too much initially, you can set a very small delay, like 10 milliseconds. The goal is to send requests faster than the server’s rate-limiting logic can keep up.

When you launch the attack, Burp will fire off hundreds of login attempts in rapid succession. If the rate limiter is implemented in a way that checks the count after receiving the request, and the processing of each request is slower than the arrival rate, the counter might not increment fast enough. You’ll see a mix of 401 (invalid credentials) responses and, if you’re lucky and the logic is weak, potentially some 200 responses before the rate limit is strictly enforced for that specific IP.

The fundamental problem this exploits is the latency between a request arriving at the server and the rate-limiting logic successfully processing and accounting for it. If you can send requests faster than 1/N requests per second (where N is your allowed rate), you can potentially bypass simple token bucket or fixed-window counters.

The most common and effective bypass technique involves accelerating the request rate beyond the server’s ability to log and count each individual request within its defined time window. This isn’t about finding a vulnerability in the authentication itself, but rather in the overhead of the rate-limiting mechanism.

The next logical step after finding a way to bypass rate limiting is to explore privilege escalation if the bypass grants access to a more privileged endpoint.