Skip to content

Schema-Based Testing Setup

This article walks through the minimum steps required to go from a fresh account to your first Schema-Based Testing run. For advanced configuration, see Docker reference; for the catalog of detection rules, see Strategies.

Prerequisites

Before you create a test policy, make sure the following is in place:

  • Security Testing subscription — contact sales@wallarm.com to activate the Security Testing subscription plan for your account. Once the subscription is assigned, the Schema-Based entry appears in the left menu under Security Testing.

  • Authentication token — Wallarm Cloud uses a token to authorize data exchange between the Docker container and your account. You can let Schema-Based Testing create the token automatically the first time you copy a Docker command, or create it in advance under Settings → API Tokens with Token usage set to Schema-Based Testing agent.

  • IP allowlist (if applicable) — when the target API is protected by Wallarm or other security tools, allowlist the IP from which the Docker command will run. Otherwise, attack requests are blocked and vulnerabilities go undetected.

  • Postman collection — a working Postman collection (and optionally a Postman environment file) that describes how to call the target API. The collection must contain functional tests for the API endpoints, the location of the target application, all required environment variables, and credentials to authenticate. Verify it runs end-to-end, for example:

    newman run my_collection.json -e my_environment.json

    If the collection cannot run on its own, Schema-Based Testing cannot run either.

Step 1. Create a test policy

A test policy bundles the Postman collection, environment file(s), and selected scan modes into a single reusable configuration.

  1. Go to Wallarm Console → Security Testing → Schema-Based → Test policies and click Create test policy.

    Schema-Based Testing - test policies list

  2. Provide a Policy name.

  3. Set Source to Postman collection and attach the Postman collection file.

  4. Optionally, attach Postman environment file(s). Attaching two environment files runs testing twice with different variable values (for example, different credentials) and then compares results.

  5. Under Working Modes, enable Active Scan, Passive Scan, or both. For each enabled mode, click Advanced settings to choose which strategies participate. By default, all strategies of the corresponding type are enabled — you can leave the defaults or narrow the selection.

  6. Save the policy.

    Schema-Based Testing - creating test policy based on Postman collection

Target URL and authentication

For Postman-based policies, the Target URL and authentication parameters are taken from the Postman collection or environment file(s). They are not configured in the policy and cannot be redefined per Docker run.

Step 2. Copy the Docker command

  1. On the Test policies tab, click the policy you just created. The policy's Docker command is displayed.

  2. Copy the command. You can adjust the Docker log level, log format, and success-criteria threshold right above the command.

    Schema-Based Testing - test policy Docker command

Step 3. Run the scan

Run the copied Docker command on a machine that has network connectivity:

  • To the API being tested (Target URL from the Postman collection or environment).

  • To Wallarm Cloud (US, EU, or ME):

    Wallarm Cloud IP addresses

    To provide Wallarm Cloud access to your system, you may need a list of its public IP addresses:

    34.102.90.100
34.94.156.115
35.235.115.105
34.94.85.217
34.94.51.234
34.102.59.122
34.94.238.72
35.235.100.79
34.102.45.38
34.94.241.21
34.94.203.193
34.94.238.221
34.94.9.235
34.94.118.150
34.94.193.9

    34.141.230.156
34.91.138.113
34.90.114.134
35.204.127.78
34.90.24.155
34.7.147.149

    34.166.215.174

A typical run prints pre-flight checks, the workflow progress, and a final security-issues summary. For CI/CD integration, environment-variable reference, report generation, mTLS, and override patterns, see Docker reference.

Step 4. See results

When the run finishes, the Test runs tab shows it with status, request count, credits consumed, and the number of detected security issues. Open the run to inspect health checks, the pipeline stages, and the per-strategy hypotheses with their verdicts. Confirmed findings are also promoted to Security Issues with Discovered by = Schema-Based Testing.

See Exploring test run results for a walkthrough.