API Authentication Attacks - using Zap Proxy, BurpSuite and Wfuzz


3 min read

To run the tests in a self-hosted environment, we can use vAPI, which is a vulnerable, adversely programmed interface that is a self-hostable API.

Running vAPI using a Docker container is fairly straightforward. Download the vAPI GitHub repo into a folder and run:

$sudo docker-compose -f docker-compose.yml --compatibility up -d

vAPI should be up and running in the background, and it can be tested by navigating to on your local machine or VM.

We are specifically trying to target api2 of vAPI, which allows user authentication by sending a POST request to with the content-type header set to application/json and the request body parameters (username and password).

We can use the FoxyProxy browser extension to capture and relay the traffic through Zap and BurpSuite.

Zap Proxy

Using FoxyProxy to capture the requests and navigate to we can use the GET request populated in Zap.

Right-click the request -> Attack -> Fuzzer to edit the request and turn it into a POST request with a content-type header of "application/json" and JSON parameters:

  "email": "test",
  "password": "test"

The list of credentials for the attack is can be obtained here: https://github.com/roottusk/vapi/tree/master/Resources/API2_CredentialStuffing

Parse the username and password fields and store them in separate text files. Highlight the "test" fields and add the corresponding filenames for the username and password.

Start the fuzzer and check to see if you're getting 200 or 401 response codes.

For this particular scenario, Zap will test one million different payload sets with every combination from the provided one thousand usernames and one thousand passwords.

Attacks similar to Burp's pitchfork feature can be performed using BurpSuite or Wfuzz. This is a more efficient way of dealing with this particular situation.


Burp's Pitchfork feature within the Intruder option is perfect for sending specific combinations of payloads from different lists in the same request. Our credential-stuffing attack requires a matched username and password list.

Using FoxyProxy, capture the request using BurpSuite and send the request to Intruder with Attack type: Pitchfork

Switch the GET to a POST request, change the path to the login endpoint, and add the content-type header and the JSON parameters. Add the "test" fields as the fuzzing positions and switch to the payloads tab.

Choose the username and password text files for each payload set and start the attack.

If you do not have BurpSuite Pro, the request speed will be heavily throttled, and running the attack at this speed is inefficient.

However, you can still use it as a proof of concept to perform similar attacks.


Wfuzz is the best way to perform the credential stuffing attack against this login API endpoint.

Wfuzz command to perform fuzzing similar to Burp's pitchfork attack is

$wfuzz -d '{"email":"FUZZ","password":"FUZ2Z"}' -H 'Content-Type: application/json' -z file,users.txt -z file,pass.txt -u --hc 401 -m zip

" -d " flag - sets the POST body

FUZZ and FUZ2Z - specifies the payload position 1 and 2 within the POST body

" -H " adds the specified header to every request

" -z " sets the payload file for username and password

" -u " sets the URL to fuzz against

" -hc " hides the response code 401 (Unauthorized)

" -m " sets the iterator function, which combines the payloads from files 1 and 2 to create matched sets.

Official Wfuzz documentation regarding the iterator function: https://wfuzz.readthedocs.io/en/latest/user/advanced.html

Output from Wfuzz with the credentials returning a 200 response code:

Wfuzz also completes the test at a much faster rate compared to Burp's community edition.

Overall, each of the aforementioned tools has advantages and disadvantages, and this exercise is useful for understanding how each one functions and when it can be applied.