API Testing on an's security blog

Exploiting server-side parameter pollution in a REST URL | Expert

Tue, 14 Jul 2026 10:53:16 +0800

Similar to this problem, our goal is to log in as administrator and delete carlos. Since we don’t have the credentials, we have to look for an API exploitation elsewhere. And the safest bet is the Reset Password functionality in the login page.

Let’s try sending a password reset request to see what it looks like:

There is no explicit client-side API call, only a POST request to the very much visible /forgot-password endpoint. This probably means there is an internal API call happening server-side, but just to be sure it’s safe to try enumerating all the common API endpoints in Intruder to check for any hidden attack surfaces:

Exploiting server-side parameter pollution in a query string | Practitioner

Thu, 09 Jul 2026 15:06:16 +0800

Our goal is to log in as administrator and delete the user carlos, but the problem is that we don’t know the password. Thankfully, there’s this convenient Forgot Password feature for us to poke into. Let’s try sending a normal password reset to administrator to see what happens: The server responds with a redacted email, that’s fair because nobody wants their PII leaked right? Let’s try adding a new nonsense param and truncate the end bit, what if something unexpected happens? Weird. The server still processes the request as normal. No change to the response length, nor the response time. Adding more nonsense params does not work either. How about sending username only then truncate the query string? It looks like truncating works! And the server demands a hidden field on top of username for a hidden API request (maybe?). But we don’t know what the hidden field name is, and based on our attempt of adding &foo=bar# above we know that the server doesn’t care about custom fields. Or does it?

Exploiting a mass assignment vulnerability | Practitioner

Thu, 09 Jul 2026 13:23:16 +0800

Our task is to buy that leet jacket, but our coffer runs dry. Just like last lab, we have to either raise our balance or make the jacket free.

While crawling through the page, I tried sending a request to /api, literally. To my surprise, there actually is a hidden documentation lying around: The GET request to /checkout seems to request the metadata for our purchase, with these attributes lying around. While the POST request is performing that purchase. So after adding the leet jacket to our cart, let’s perform the GET request to see the response: The server returns a JSON object with very clear attributes. One thing to note though is that the chosen_discount attribute is left conveniently there for us, while no explicit option for discount is present on the page (perhaps it’s for a later sales period?). Let’s try sending the discount attribute along with our purchase in a POST request to /checkout, with say 100% discount rate? Let’s try this out: Looks like the request has gone through, and we got ourselves a slick jacket free of charge. Nice.

Finding and exploiting an unused API endpoint | Practitioner

Thu, 09 Jul 2026 10:32:16 +0800

Our task is to purchase the hackerleet hoodie, but we are also broke af. Upon attempting to purchase the thing without septims, we are hit with an expected denial:

One may think to try illicitly manipulate our store balance, but there is no JS or API call present that queries for an user’s current balance. So that’s bust.

However, notice how whenever we fetch a GET request to a store item, an API request to /products/./price is called: Obviously, if we are not able to increase our coffers, we should make the shopitem free right? Since the response body is a JSON object, it’s expected that the request body to change the price should be a JSON object too. Let’s try sending a POST request to change the price to zero: Too bad that we are hit with a 405, but there is one convenient header they so kindly left for us. The only allowed methods are GET, which we’ve just covered, and PATCH. Since we cannot create a new resource with POST, let’s try updating the resource with PATCH instead: Looks like that didn’t work. It’s sad to say but I’ve spent an embarassingly long amount of time trying to figure out what went wrong here, but in reality it’s just that the price is a string, and the backend demands an integer: So after setting the price of leet to free, we are able to buy it no problemo:

Exploiting an API endpoint using documentation | Apprentice

Thu, 09 Jul 2026 09:32:16 +0800

When we want to test for APIs, we first need to find out as much information about the API as possible. To do that, we must identify API endpoints. This can be done through reading developer’s API doc or fuzzing the paths using Intruder.

In this lab, no doc is provided meaning we have to stick with the latter method. Funnily enough, the documentation endpoint is literally /api/, that’s it: