This article explains how to scan a standalone API target with Probely.

To scan an API, we need its specification, the schema. You can define it with an URL pointing to the schema or uploading it to Probely. The former has the advantage of us fetching the schema before every scan, ensuring we always get the most up to date version.

Probely supports APIs with different authentication methods. You can set a fixed API key in a custom header or configure a login endpoint from which you obtain an authentication token.

You can also define custom parameter values that replace those found in the schema. This allows you to override example values or to ensure domain-specific values are properly filled.

Scanning an API is a simple three-step process:

This article describes these steps in detail, covering multiple authentication scenarios.

Go to https://plus.probely.app/targets/add to add a target.

Set the URL field to the API base URL, i.e., the domain from which your API is actually serving clients.

At Is this an API target?, select either OpenAPI or Postman Collection, and then choose between entering your API schema URL or uploading it. We support both JSON and YAML schemas.

Setting the schema URL has the advantage of Probely fetching it before a scan, so we always scan the API's latest version.

When setting the API, if the server defined in the schema is not within the scope of the target, a warning will appear. You can then opt to ignore the server tag value from the OpenAPI schema file and use the target URL instead.

After adding (and verifying, if needed) the target, go to its settings.

The settings differ if you are configuring an OpenAPI or a Postman Collection API:

API targets have a few different settings when compared with a non API target:

Let's go over these settings:

API Target Authentication (OpenAPI only)

Scenario 1: you have a fixed API key that must be placed in all requests, in a header.

This is the simplest scenario, as you only need to add a Custom Header with the appropriate header name, Authorization in this example, and its value.

Scenario 2: you have a fixed API key that must be placed in a specific parameter.
In the API Scanning Settings section, add an API Parameter Custom Value, with the field's name and the respective value. The value should be your API key.

You can add multiple entries if your API key location varies. For instance, if you use key for GETs and token for POSTs, add both fields with the same value. Probely will use the right one for each endpoint.

Scenario 3: obtain a token from an API endpoint.

In this scenario, you get the API token from an endpoint that authenticates you, for instance, with a pair of credentials, such as username + password.

This authenticating pattern is often found on APIs that support web applications: the user authenticates himself with his username and password, obtaining a token used on all requests thereafter.

Go to the API Target Authentication section on the target settings and fill in the appropriate values:

Click Fetch to perform the authentication. If the authentication fails, an error will be displayed. If the authentication succeeds, the Token Field Name will list the fields obtained in the authentication response. Choose the field that contains the authentication token.

Next, at Place Token In, choose where to place the token in the API requests. For most cases, the token is placed in a header. The other available option is cookie.

At Field Name, enter the name of the header or cookie that will hold the token.

Optionally, set a Value Prefix for the token value. This is often needed for JWTs. For instance, if your API requires you to send a header Authorization: JWT <token>, set the following values:

Press Save.

API Scanning Settings (OpenAPI only)

Here you can override or set values for the endpoint parameters described in the schema.

Our scanning engine has a set of predetermined values for the most common parameters, such as email, address, and dates.

If we cannot infer the adequate value for a parameter, we use a default value. You can override that behavior by setting specific values, such as email and the product_id, as shown in the example below:

Just press Scan Now, and the scan will start in a few seconds. You can follow the scan progress on the scan page.

Afterwards, you can download a coverage report in CSV format that lists the endpoints parsed from the schema and the respective HTTP response code. The coverage report is a good tool to help you understand if there were endpoints that failed.

To learn more about the coverage report, click here.