> For the complete documentation index, see [llms.txt](https://allthewriteups.gitbook.io/book/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://allthewriteups.gitbook.io/book/portswigger/academy/api-testing.md). # API testing ## SUMMARY PortSwigger API testing labs focus on RESTful and JSON APIs (Application Programming Interfaces). Websites and APIs are closely related, therefore classic web vulnerabilities are usually also applicable in the scope of API testing. This is important to note because some of the OWASP API top ten may be covered in other [Web Security labs](https://portswigger.net/web-security/api-testing/top-10-api-vulnerabilities). ## KEYWORDS API, mass assignment, server-side parameter pollution. ## REFERENCES ## API-01: Exploiting an API endpoint using documentation This lab was solved by capturing a request to the endpoint `/api/user` and enumerating the allowed communications options. This is done with the `OPTIONS` method.
The application replies method `DELETE` is allowed in the endpoint, so just send a delete request for user `carlos`
You have solved the lab. ## API-02: Finding and exploiting an unused API endpoint You have $0 credit and you have to buy an expensive jacket. Theoretically it could be done in two ways: you could either raise your credit or lower jacket's price. Regarding first option, there is an endpoint for account managing `/my-account`, but we cannot modify anything there. Regarding second option, if you browse the jacket and capture the request you'll see a request to endpoint `/api/product/1/price`. Maybe we can lower the price here. Let's enumerate the endpoint methods to have an idea what we can do here.
It seems we can modify (patch) it. Let's see how the endpoint works, first we send an empty request and inspect the error message.
It seems only JSON content/type is allowed. So change the request type and try again.
The application kindly shows us the name of the parameter we have to use. So let's update the request to change the jacket's price to $0.00.
Now you can buy the jacket with your empty wallet, just place the order and solve the lab. ## API-03: Exploiting a mass assignment vulnerability In a [mass assignment vulnerability](https://owasp.org/API-Security/editions/2019/en/0xa6-mass-assignment/) we are able to modify data items that we should not normally be allowed to access. Navigate to the jacket article, add to cart and place an order. Inspect the traffic, there are 2 requests to this endpoint `/api/checkout` The first one is a GET request containing several interesting parameters, including one that seems to be used for discounts.
The second one is a POST request using only 2 of the parameters, `product_id` and `name`, that is replied with an "Insufficient funds" error message.

h

We have disclosed the parameter for discounts before and have a view of how purchase orders are processed. Let's test for a mass assignment vulnerability that might allow us to add a discount (for example, granting you a 100% discount).
The vulnerability is confirmed, order is processed and the lab is solved. ## API-04: Exploiting server-side parameter pollution in a query string We are challenged to log in as the administrator and delete user `carlos` Start by trying a password reset for user `administrator`
As explained in the [Academy](https://portswigger.net/web-security/api-testing/server-side-parameter-pollution), in a server-side parameter pollution we are able to manipulate the internal server request to the API with an appropriate input. This is normally done by adding a truncation character. In this example, the website adds internal parameters to the user input before sending the request to the internal API. We can add our own parameter if the application fails to correctly encode the input. Let's try with a truncation character such as #.
This suggests we have been successful in truncating the request. The application was expecting a `field` parameter that is not being received because of the # character. Knowing this, we can inject our own `field` parameter. For this we use a & character and end the string with another truncation.
This confirms the application is vulnerable to server-side pollution. Doing a couple more of tests we find out the `field` parameter is used to query account attributes such as the username or email.
Once the vulnerability is confirmed, now we have to find a parameter to exploit so we can log in as administrator and delete the account. In the source code of the file `/static/js/forgotPassword.js` we find out the `/forgot_password` endpoint expects a parameter called `reset_token`
If we use this in the `field` parameter we get a password reset token for user administrator.
And with this token you can reset administrator's password by accessing endpoint `/forgot-password?reset_token`
You have solved the lab.