Request for Guidance: Writing a Functional Fuzzer for OpenAPI Specs with Missing Keys

[beam-me-up]

I'm interested in learning how to write a functional fuzzer for OpenAPI specifications that lack keys. To illustrate, I have provided a sample OpenAPI spec below:

/users:
    post:
      description: This API is used to get the list of users based on the input data.
      requestBody:
        content:
          application/json:
            schema:
              type: string
        required: true

In this example, the OpenAPI spec is missing keys that are typically present. I would greatly appreciate some guidance or best practices on how to approach fuzzing such specifications effectively.

[en-milie]

I'm not sure I understand the question. Can you please provide additional context with a more detailed example.

[beam-me-up]

Sure @en-milie, here is the curl command sample for the above request.

curl --location --request POST 'http://localhost:8080/users' \
--header 'Content-Type: application/json' \
--data-raw '"dGVzdERhdGE="'

This is a valid body. As a content-type as json, the body is expected to have a JSON object, array or literal.

[en-milie]

Hi @beam-me-up. I want to resume this issue. And want to check if my understanding is correct. You would like to be able to check if a certain request body is missing fields that you would typically expect? And deduct this from the endpoint name and http method? Or specify the expected fields in the functional fuzzer file? It will help if you can provide a full example, like:

• a full OpenAPI sample spec
• what additional data you would expect to feed CATS with, either via the functional fuzzer file or arguments
• what would you expect the output of CATS to be

Thanks!

[beam-me-up]

Hi @en-milie,

Apologies for the delay.

For a request like this:

curl --location --request POST 'http://localhost:8080/users' \
--header 'Content-Type: application/json' \
--data-raw '"dGVzdERhdGE="'

If there's no JSON payload and only raw content in the body, I was curious if Functional Fuzzer supports testing this scenario. It's not a mandatory requirement. A simple "yes" or "no" response would be sufficient, and we can close this accordingly.

[en-milie]

Currently it's a 'no'.