Burp Suite Repeater lets you take an HTTP request Burp intercepted, tweak it, and send it again and again to see how the server responds.
Here’s a common scenario: you’ve found a potentially interesting request in Burp’s proxy history, maybe a POST request to /api/users with some JSON data. You want to see what happens if you change a value, add a field, or try a different HTTP method.
Right-click on that request in the proxy history and select "Send to Repeater."
Now, in the Repeater tab, you’ll see your request in the left-hand pane. You can edit anything here: the URL, the method (GET, POST, PUT, DELETE, etc.), the headers, and the body.
Let’s say the original request looked like this:
POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 34
{"username": "alice", "level": 1}
You can change {"username": "alice", "level": 1} to {"username": "bob", "level": 5} and click the "Go" button. The right-hand pane will show the raw HTTP response from the server, including headers and body, along with a formatted view. You can see the status code, response time, and the content.
You can also change the method. What if you try sending the same data with a PUT request instead of POST?
PUT /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 34
{"username": "alice", "level": 1}
Click "Go" again. Observe the difference in the response. Maybe PUT is not allowed, or it updates an existing user.
This is invaluable for understanding how an application handles different inputs and methods, uncovering vulnerabilities like insecure direct object references, privilege escalation, or command injection by manipulating parameters.
Consider this request that seems to be fetching user details:
GET /api/v1/users/12345 HTTP/1.1
Host: example.com
Authorization: Bearer abcdef12345
In Repeater, you can try changing 12345 to 67890 to see if you can access another user’s data. You can also try removing the Authorization header entirely to see if authentication is bypassed.
The true power comes from iterating. You can send a request, see the response, modify it slightly based on what you learned, and send it again. Burp keeps the request history for the current tab, so you can easily revert to previous versions or compare subtle differences.
For example, if the response for GET /api/v1/users/12345 was a JSON object with user details, and for GET /api/v1/users/67890 it was a 403 Forbidden error, you know that direct ID manipulation is likely blocked for unauthorized users. But what if you try GET /api/v1/users/../../etc/passwd? (Though this is more relevant for path traversal vulnerabilities).
A key insight is that the server’s interpretation of your request can be highly sensitive to the exact phrasing, casing, and encoding of headers and body parameters. Repeater excels at this fine-grained control. You can manually craft malformed requests that might trigger unexpected behavior, such as sending an empty Content-Length header or an invalid Content-Type.
When you’re working with complex authentication schemes, like OAuth tokens or session cookies, Repeater allows you to easily modify these tokens. You can copy a valid token from one request, paste it into another, and see if it grants you access to resources you shouldn’t have. Similarly, you can try manipulating other headers like X-Forwarded-For to spoof IP addresses, or User-Agent to see if the application behaves differently based on the client.
The "Analyze" button in Repeater is also useful. If you have multiple requests that you’ve sent, you can select them, click "Analyze," and Burp will show you a comparison of the responses, highlighting differences in headers, body, and status codes. This is a quick way to spot patterns or anomalies across a series of tests.
The next step after mastering Repeater is often using Burp Intruder to automate these kinds of repeated, slightly modified requests across a larger set of values or parameters.