Burp Repeater lets you reissue an interesting request over and over again. This lets you study the target website's response to different input without having to intercept the request each time.
To use Burp Repeater, you can send a request to it from one of Burp's other tools. Burp Repeater makes it much simpler to probe for vulnerabilities, or to manually confirm ones that were identified by Burp Scanner, for example.
We recommend following the tutorial below to learn how to use Burp Repeater.
For more detailed information, please see the full documentation.
In this example, we'll send a request to Burp Repeater from the HTTP history in Burp Proxy. We'll then use Burp Repeater to reissue the request with different input to see what effect this has on the response.
Open Burp's browser, and use it to access the following URL:
https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-error-messagesClick Access the lab and log in to your PortSwigger account if prompted. This opens your own instance of a deliberately vulnerable shopping website.
In the browser, explore the site by clicking on a couple of the product pages.
In Burp, go to the Proxy > HTTP history tab.
Notice that each time you access a product page, the browser sends a GET /product request with a productId query parameter.
Right-click on any of the GET /product?productId=[...] requests and select Send to Repeater.
Go to the Repeater tab. Click Send to issue the request and see the response from the server.
Change the number in the productId parameter and resend the request. Try this with a few arbitrary numbers, including a couple of larger ones, to see if this has any effect on the response.
The server seemingly expects to receive an integer value via this productId parameter. You can use Burp Repeater to send a different data type, and see what happens.
Send another request where the productId is a string of non-numeric characters.
Observe that sending a non-integer productId has caused an exception. The server has sent a verbose error response containing a stack trace, which may disclose useful information.
Use the arrows to step back and forth through the history of requests that you've sent, along with their matching responses. The drop-down menu next to each arrow lets you jump to specific requests in the history.
This is useful for returning to previous requests that you've sent in order to investigate a particular input further.
Testing different input in this way is one of the most common tasks you will perform during manual testing with Burp Suite.
You have now learned how to edit and reissue requests, and view the responses, using Burp Repeater. To learn more, refer to the links below:
You can also practice using Burp Repeater and other Burp Suite features with the deliberately vulnerable "lab" websites on our Web Security Academy.