Manually Testing Your API (API BLA)

In some limited cases, an API might be incompatible with the standard AutoAPI onboarding process, where a user uploads their API documentation for fast automatic scanning. In this scenario, you can request manual testing of your API by the Black Duck Threat Research Center (TRC). This is also called an API Business Logic Assessment (BLA).

To request manual API testing, review the following information and then contact Customer Support to provide your API documentation in a compatible collection format.

Prerequisites

Before manual API testing can begin, the following information must be provided so the TRC can verify that all API operations return successful responses.

If a collection is provided that contains operations which are not intended to be tested, these must be clearly specified as excluded.
Prerequisite Description

HTTP Method

Examples:

  • DELETE https://example.com/api/users?param1=value1

  • GET https://example.com/api/orders?var;param2=value2&param3=value3

Domains

Domain(s) should be provided and must be accessible by us. Internal domains will be configured with our satellite appliance. If an Endpoint URL exists on multiple domains, each Endpoint URL on each unique domain will be considered a separate operation. Example:

GET https://example.com/api/orders?param2=value2&param3=value3

Endpoint URL Path

Endpoint URL Path (including values for path parameters, if applicable). Example:

  • DELETE https://example.com/api/users?param1=value1

  • GET https://example.com/api/orders?param2=value2&param3=value3

Required Parameters

If an operation must be sent with mandatory parameters and parameter values in order to receive a successful response, this test data must be provided. Examples:

  • GET https://example.com/api/orders?param1=value1&param2=value2

  • DELETE https://example.com/api/users/215426?param2=value2

Request Headers

Required Request Headers and Associated Values

Successful Responses

Examples of the response that a user of the API can expect to receive through normal usage of the API.

In most cases, a '200 OK' response will be assumed as a successful response, unless specific successful responses are provided.

If any operations are intended to return errors, redirects, or unauthorized responses in order to test for access control bypasses or other logic flow circumvention, these must be specifically identified.

Authorization method and/or valid credentials (if required)

If any of the operations require valid credentials or other forms of authorization, such as tokens for authorization headers, these must be provided. If authorization tokens are provided, we must ensure that the tokens will not expire before testing can begin.

If authentication operations are provided, but are not in scope for testing, these must be clearly identified as excluded from testing.

Scripts (if required)

If an operation requires the use of a script in order to generate dynamic values for each request, this script must be provided.

Business Logic Flow

If the business logic flow requires API operations to be submitted in a particular order, this information must be provided. (E.g., an operation may require a dynamic value that is returned after submitting another operation).

Acceptable Documentation Types

Documentation Type Description

Collections

Postman-compatible or SoapUI-compatible collections are required, and are the fastest way to get the API scoped and onboarded for testing.

Examples of Postman-compatible documentation in JSON or YAML format:

  • Open API 3.0 specifications

  • Swagger 2.0 specifications

  • Postman Collection v2.1

Examples of SoapUI-compatible documentation:

  • WSDL format (file or URL)

  • REST API in XML format

  • SoapUI projects

To provide additional context, you can attach a video or document that explains how the collection is meant to be run.

When you are ready to provide the above information, please contact Customer Support.