StackHawk
Hamburger Icon

Custom Test Data
for GraphQL
APIs

austin-pearigen-hex-bw

Austin Pearigen|December 8, 2022

Test your GraphQL APIs for business logic vulnerabilities with StackHawk's Custom Test Data feature.

Why is this new feature important? 

The parameters defined in a GraphQL API are meant to represent real data, in other words, actual usernames, asset IDs, query strings, and so on. Using genuine data for these parameters triggers authentic logic from your application and activates more branches of your code.

For instance, for a password update mutation in a GraphQL API, if a username or ID is provided that does not exist within the context of the application, a simple 404 is returned on the resource lookup, and none of the actual password reset code is invoked. However, if the resource can be found, all of the password reset code is exercised with the parameters provided.

This scenario illustrates how Hawkscan’s new feature, ‘Custom Test Data for GraphQL APIs’, enables deeper security testing of GraphQL APIs.! Using this new feature, users can configure lists of values they want to use in a scan for each defined parameter and one of the values will be chosen randomly for each path that parameter belongs to. 

How is this new feature configured?

To supply custom values for a GraphQL API’s parameters, you need to update your `stackhawk.yml` file. Under the `app.graphqlConf` section, a new array field called “customVariables” is available, which represents a list of fields and corresponding lists of values for each key. The key represents the parameter in your GraphQL schema, and HawkScan uses the list of values to choose one on the fly when scanning a GraphQL API. 

I don’t want to supply my own data, but I do want more realistic values.

Sometimes existing data isn’t always necessary and properly formatted values will still be more effective than generic default values. Leveraging the Faker library, HawkScan can now generate authentic data for a GraphQL API with a little configuration.

For instance, if a request has a phone number as one of its parameters where the type is a string and the format is phone, an actual phone number can be generated rather than a default value string that has no relation to a phone number. To use these faker values, the `fakerEnabled` parameter in the graphqlConf section of the `stackhawk.yml` file should be set to `true`. When enabled, HawkScan generates a realistic value for any parameters that are supplied in the `customVariables` section and have a provided value with the prefix `$faker:` followed by the desired format. For example, to generate an email address for a parameter, a single value should be provided “$faker:email”. Faker prefixed formats can be supplied with other custom variables, or as a singleton list to guarantee a Faker value is generated. A complete list of the available formats is available (https://docs.stackhawk.com/hawkscan/configuration/openapi-configuration.html#generating-smart-values-for-parameters)[in our documentation] (Need to put this list in a better, more commonplace in the docs for gql to share as well.)

graphqlConf:
 enabled: true
 schemaPath: /graphql
 requestMethod: POST
 uriMaxLength: "4000"
 maxDepth: "7"
 introspection:
   requestsPerCycle: "10"
   requestDelay: "1000"
 batchQueries: false
 operation: ALL
 filePath: ""
 fakerEnabled: true
 customVariables:
   - field: firstName
     values:
       - customFirstName1
       - customFirstName2
   - field: lastName
     values:
       - customLastName1
       - customLastName2
   - field: username
     values:
       - $faker:email

📺 Watch a Quick Demo



Austin Pearigen  |  December 8, 2022

Read More

Add AppSec to Your CircleCI Pipeline With the StackHawk Orb

Add AppSec to Your CircleCI Pipeline With the StackHawk Orb

Application Security is Broken. Here is How We Intend to Fix It.

Application Security is Broken. Here is How We Intend to Fix It.

Using StackHawk in GitLab Know Before You Go (Live)

Using StackHawk in GitLab Know Before You Go (Live)