Security scan, access matrix and webhook inbox

Scan a project for security gaps, check who can reach what, catch webhooks and try bad inputs. "Test" › "Security" and "Build" › "Mocks, streams & docs" hold them.

In short

The project-wide tests beyond plain checks live in two views. "Security", under "Test", opens on "Results" - one list of what every check found - and holds a security scan of your saved requests and an access matrix that sends the same requests as different people. "Mocks, streams & docs", under "Build", holds the webhook inboxes that catch what other services send, with the mock server, streams, MCP servers and published docs. "Try bad inputs" is on a request. Heavy and active tests run only against a site you proved is yours.

Before you start

See every result in one list

  1. Open "Test", choose "Security" and choose a project. It opens on "Results".
  2. Read each row, newest first: the check - "Security scan", "Who can do what" or "Robustness" - with its environment, what it found and when. "Nothing found" is clear; "2 to look at" and "3 found" need you.
  3. Click a row's name to open it where it lives: a scan or a matrix opens its own tab, and bad inputs open their request.

With nothing run yet it says "No results yet" and offers "Run a security scan".

Run a security scan

  1. Open "Test", choose "Security", choose a project and open "Security scan".
  2. Press "Scan this project".
  3. Read what it found by severity (High, Medium, Low, Info), each with its OWASP API Security item and how to fix it.
  4. To go further, switch on "Active checks" - it also tries methods such as TRACE and replays requests without their credentials, on proved hosts only.

One scan checks up to 25 of the project's saved GET and HEAD requests - never a request that changes data. It looks for:

Prove a site is yours

  1. Open Settings, then "Verified sites", and press "Prove a site".
  2. Enter the site's address, such as https://api.example.com. A proof covers that host and port only.
  3. Press "Get a token".
  4. Put the token on the site: serve a file at the address shown with the token as its whole text, or send the header shown from the site's root page.
  5. Press "Verify now".

A proof lapses 30 days after its last check, so keep the token on the site; Settings warns you before it lapses. The proof is checked again every time a heavy test starts, and the test connects only to the address the proof was fetched from. Only people who manage the workspace's settings can add or remove a proof.

Who can do what

  1. In "Security", open the "Who can do what" part and press "New access matrix".
  2. Choose the requests, the people (each authentication profile is one person or role; add "Nobody signed in" as another), and an environment.
  3. Press "Save matrix", then click a cell to say what should happen: "In" (let in) or "Out" (kept out).
  4. Press "Run the matrix".

Each cell shows what happened: let in, refused (401 or 403), hidden (404), another 4xx, a server error, no answer or not sent. A cell is flagged only against what you expected - most of all "let in but should be kept out", such as one user reading another's records.

Webhook inbox

  1. Open "Build", choose "Mocks, streams & docs" and open "Webhook inboxes". Press "New inbox" and give it a name such as Payment events.
  2. Press "Copy address" and paste it into the other service. Only people who manage the project see the address.
  3. Watch the requests appear as they arrive: method, path, query, headers and body.
  4. To make a suite wait for one, edit a step and switch on "Wait for a webhook after this step". Then choose the inbox, optionally a method, text the path or body must contain, and how long to wait (up to 60 seconds).

The step passes only when a matching request arrives after the step started.

  1. Open the inbox and press "Add a schema". You need to manage the project.
  2. Paste a JSON Schema and save. Every request the inbox keeps is checked, and so is every one that arrives after.
  3. Each request now says "Fits" or "Does not fit". Open one that does not fit to read where.
  4. To make a suite step count only a request that fits, switch on "It must fit the inbox's schema" on that step.
  1. Open a received request and press "Send again". You need to be able to edit the project.
  2. Give the address to send it to, then press "Send".
  3. Read the status and the time it took. It counts as one send, like any other.

Its method, headers and body are sent as they arrived. Credentials were masked when it arrived, so they are not sent. A request with a binary body cannot be sent again.

Try bad inputs

  1. Open a saved request's "Bad inputs" tab, or "Try bad inputs" in its menu.
  2. Read the verdict for each of up to 40 inputs the API should refuse. They include an empty body, broken JSON, a wrong type, a missing required field and a null. They also include values out of range, text that is too short, too long or oversized, and a value that is not allowed.

Good to know

If something goes wrong

Related