API Testing with Postman Collections

This article describes how to set up vulnerability scanning of your API using Qualys WAS with a Postman Collection. Initial support for Postman Collections in WAS was released in October 2019.

Postman Collections

One of the newer features of Qualys WAS API scanning is support for Postman Collections. A Postman Collection is an executable API description available in the Postman API testing suite. Collections can be created manually or via importing a Swagger/OpenAPI/RAML/WADL file. The collection files can be local or hosted. Many QA and functional testing teams are already using Postman Collections to automate their testing and security teams using Qualys WAS may be able to leverage those collections.

Testing

Test Requirements

Postman Collection – This is the collection that contains all of the API requests

Environment Variables (optional) – These are variables specific to the environment

Global Variables (optional) – These are variables that apply to all collections in Postman

Authentication Setup

Do not use form authentication – APIs are not HTML-based

Header injection for API keys/tokens – If access tokens are provided outside of the API, you will need to use header injection. A common example would be an API secret and API key.

Server-based authentication is still a possibility – Basic and NTLM authentication are possible and if needed should be created as a normal authentication record in WAS.

Working with Postman

Postman Collection

If API documentation exists, import the file into Postman to create a Postman Collection.

If no, documentation exists, you can build the collection manually. Here is an example collection built off the Tiredful API test target. It contains the requests to the API endpoints.

This request is an example of a POST request. The request goes to the endpoint, http://10.0.0.232/api/v1/trains/ and has a POST body of {“PNR”: “9875-4581-234”}.

The URL could also be held in an environment variable, {{URL}}. If that is the case, you would also upload the environment variables file.

Working with Data

This is the first request of the collection. This is a typical OAuth2 authentication flow. It is a POST request that contains a username, password, grant_type, client_id, and client_secret.

This is the response. It contains the access_token, token_type, expires_in, refresh_token, and scope. The access_token is the value that will need to be passed for authentication. It is similar to a cookie in that aspect.

One of the best features of Postman is the ability to create tests. Tests are written in JavaScript and can perform many actions. The most useful for testing is the ability to use data in the response to create variables. These variables allow passing data between requests.

In this example, we can capture the authentication token returned from the login request, save it as the environment variable “token” and then use it in the next request:

This is the next request that requires authentication. We create an Authorization header with the value Bearer: {{token}}. The {{token}} will be replaced by the variable when the request is made.

Additional Scan Considerations

Path Fuzzing Rules

Path fuzzing rules can be used to further enhance testing. APIs typically have “friendly” URLs. These URLs appear to web scanners as folders due to the way they are structured. Take this URL:

In this example, 2 will appear as a folder. It is actually the value of the parameter articles. In a standard web application, this URL could be http://10.0.0.232/api/v1?articles=2. To ensure the scan will test the fields as parameters you will need to create rules to guide the testing.