Hello, Fuzz!

We have prepared an instance of the Swagger Petstore API for you to try fuzzing. The Swagger Petstore is a stand-alone REST API server which implements the OpenAPI 3 Specification.

Fuzz the Swagger Pestore API for 20 seconds by running the following in your terminal...

mapi run \
     petstore 20 'https://demo-api.mayhem4api.forallsecure.com/api/v3/openapi.json' \
     --url 'https://demo-api.mayhem4api.forallsecure.com/api/v3/' \

...once the run completes, visit your dashboard to see the results!

What just happened?

Let's break that command down, to see what happened:

mapi run

Use the CLI to run a fuzzing job.

ℹ️ Check out mapi help if you want to explore some of the other things the CLI can do!


Use (and create, if it doesn't already exist) a "target" named petstore for this run. We'll come back to targets in more detail later. For now, a short name that uniquely identifies the API being tested is perfect.

ℹ️ Targets are used to group related fuzzing jobs.


Run this fuzzing job for just 20 seconds.


URL of the API specification.

The fuzzer currently accepts either OpenAPI 3.0 specification, Swagger 2.0 specification or Postman 2.x collections in json or yaml format. HTTP Archive (HAR) is also supported by converting a .HAR file into an OpenAPI 3.0 specification.

ℹ️ You may also use an API specification file from your local file system.

--url 'https://demo-api.mayhem4api.forallsecure.com/api/v3/'

Tells the fuzzer, which is running locally on your computer, to address its tests to the petstore demo API on our network. This method will work for APIs that are:

  • Behind a corporate firewall
  • On localhost
  • In a private network
  • On the public internet

If the machine running the CLI can access the API - then we can fuzz it!

Local Fuzz


Runs the fuzzing job with an interactive, terminal-based user interface. This option should be omitted in a continuous integration environment.

You will see the following UI in interactive mode:

Status UI

The status UI contains a fair amount of information:

  • A progress bar at the top, based on the duration of the job and elapsed time.
  • The job logs. If the job doesn't start properly, or runs into trouble, this is where you should see information on how to resolve the issue.
  • The status codes that the fuzzer observed per endpoint. This will help you determine if the fuzzer is covering the endpoints and status code you expected. For instance, if you see only 401 responses, then that means the fuzzer probably needs help with authentication. We cover this in more details in “Troubleshooting".

The UI has a few navigation keys that might be handy:

  • q, ^C or <Esc> to quit
  • <Tab> to switch focus between widgets
  • <Space> to make the current widget full screen
  • Arrow keys for horizontal and vertical scrolling

In your run you should see a number of red endpoints which means that at least one 500 response code is observed. That means we just found some bugs! You should also see a number of green endpoints. These mean that at least one 2xx response has been observed.

ℹ️ We won't cover authentication just yet but we will cover it later in the API Authentication chapter.


You are already off to a great start on your API fuzzing journey! In this chapter you learned how to:

  • Install the latest version of the Mayhem for API CLI
  • Fuzz APIs and monitor fuzzing progress

This is a great time to talk about the main output of fuzzing: bugs. You just found a few of them in our demo API, so let's figure out how to dig into them a bit more.