Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

Problem statement

The Postman desktop application and cloud platform allow developers to design, test, and document APIs.

API testing is done using Postman Collections: files that contain the request(s) format and URL(s) to call a specific API. Collections may also contain secrets that are needed to call the API, such as API keys, OAuth tokens, etc. These secrets need to be handled with care, in order to avoid:

  • Developers sharing a Collection with each other, with or without realizing that it contains sensitive secrets.

  • Developers pushing a Collection to a code repository, with or without realizing that it contains sensitive secrets.

  • Sensitive/production secrets getting mistakenly uploaded to the Postman cloud platform.

Recommendations

The following recommendations can help prevent such issues:

  1. Improving developers' usage of Postman:

    1. Developers should store secrets in Postman environment variables, instead of directly embedding them in the Collection’s request or code, in order to properly separate code/logic from secrets.

    2. Developers should leverage the “initial” and "current“ value functionality in order to avoid mistakenly sharing their own API key when sharing a Collection file.

      1. The "current” value should be used to store the developer’s own/private secrets, as "current“ values do not get shared as part of a Postman Collection or Environment.

      2. More details are available at https://blog.postman.com/how-to-use-api-keys/ .

    3. Developers should leverage the “secrets” variable type, in order to explicitly flag secrets in their Collections.

      1. Such secrets will also be masked when displayed on-screen.

      2. More details are available at https://blog.postman.com/introducing-secret-variable-type-in-postman/

  2. Setting up an "approved“ Postman workspace with secrets scanning:

    1. Provide developers with one or a few "approved“/official Postman cloud workspace(s) that they are expected join and use, when using Postman.

      1. To ensure that there is a central location for all of the organization’s Postman Collections.

    2. Configure Postman’s token scanner functionality to enable Custom Alerts, in order to have it scan for your own organization’s secrets, within Postman Collections.

      1. More details are available at https://learning.postman.com/docs/administration/token-scanner/#custom-alerts .

  3. Being able to detect Postman secrets on employee laptops:

    1. To better understand usage and risk, consider leveraging existing endpoint security software to scan company-issued laptops for:

      1. Secrets embedded in Postman Collection files and Postman Environment files.

      2. Postman app installs that are not logged into the approved Postman workspace(s) within Postman cloud.

  • No labels