Research Academy
My account Customers About Blog Careers Legal Contact Resellers
The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Target page only keeps the record of the last API request if the API endpoint is the same and the REST method is not the same.

Brijesh | Last updated: Jul 11, 2023 01:47PM UTC

I was trying to record the API for an application. I observed that the Burp Target page only keeps the record of the last API request if the API endpoint is the same and the REST method is not the same. For example, we have four api as below: GET /api/v1/users/12345 PUT /api/v1/users/1235 DELETE /api/v1/users/12345 OPTIONS /api/v1/users/12345 If the execution of the APIs happened in the same order as above, then the Burp Target page only keeps the record of the "OPTIONS /api/v1/users/12345" request. The other three requests are not recorded in the Target page. I am using Burp Suite Professional v2023.6.2

Hannah, PortSwigger Agent | Last updated: Jul 12, 2023 10:48AM UTC

Hi The Site Map is only able to record one item for each entry in the Site Map. You should be able to see your previously sent requests in the Logger tab. If there are any requests of interest, you can send these to the Organizer tab to make notes against them.

Brijesh | Last updated: Jul 12, 2023 05:57PM UTC

Hi Hannah, The site map only keep only one entry even though the REST methods are not same e.q. one GET API call and other PUT API call? For example, if there are 2 requests with same end point but different REST method then site map only keeps the record of lastly executed REST method. This seems a bug. It used to work earlier as I remember.

Hannah, PortSwigger Agent | Last updated: Jul 14, 2023 04:12PM UTC

Hi Could you tell me the version that you last saw this working in? We use the path and parameters to distinguish between different items in the site tree. If you have a request that uses different parameters, then this will be shown under a different entry.

Brijesh | Last updated: Jul 14, 2023 07:54PM UTC

Hi Hannah, I can't recall the specific version in which it was functioning properly, but the current behaviour is a bit strange. I executed the following API calls in the exact order as mentioned (both the POST and PUT APIs have the same body parameter): ------------Case 1---------------------------------------- GET http://example.com/user/1 POST http://example.com/user/1 PUT http://examle.com/user/1 In the Target tree, the API appeared as follows: POST http://example.com/user/1 PUT http://examle.com/user/1 ------------Case 2---------------------------------------- POST http://example.com/user/1 PUT http://examle.com/user/1 GET http://example.com/user/1 In the Target tree, the API appeared as follows: POST http://example.com/user/1 GET http://example.com/user/1 ------------Case 3---------------------------------------- POST http://example.com/user/1 PUT http://examle.com/user/1 GET http://example.com/user/1 DELETE http://example.com/user/1 In the Target tree, the API appeared as follows: POST http://example.com/user/1 DELETE http://example.com/user/1 Therefore, it seems that the target tree retains only one record from GET, PUT and DELETE methods if the API URL is the same. If I follow the behaviour you suggested, "we use the path and parameters to distinguish between different items in the site tree," then according to this, the Target tree should not list both the POST and PUT methods in the above case 1. However, it does list both the POST and PUT methods, even though the path and parameters are the same. Thanks, Brijesh

Hannah, PortSwigger Agent | Last updated: Jul 21, 2023 10:49AM UTC

Thanks for letting us know about this. We'll raise a ticket to investigate this behavior further, and look into whether any changes need to be made to this behavior. If there's anything else we can help with, then please let us know.

Brijesh | Last updated: Jul 21, 2023 06:44PM UTC