Postman is an extremely popular application for developers testing remote web APIs. It lets you craft HTTP requests, interact with their responses, and go through the history of what you’ve sent and received.

Many of these HTTP requests are authenticated, meaning that the application deals with API keys, login tokens, credentials, etc.

In May, Postman pivoted to be a cloud-only product for many of its features.

Postman’s Security Risk

When you log in to Postman, it automatically syncs all data to their cloud service – including sensitive data contained in these requests. For example, here is the cloud view of Postman when all I’ve ever used was the on-premises application.

Changes to the Postman Threat Model

Cloud connectivity is of course not a security threat, but it does mandate that the product or company account for the new risks in the threat model.

This change introduces several major changes to Postman’s security risks:

• A user’s self-managed Postman account credentials now provide access to any production secrets they may been using. If your organization enforces identity separation when managing production resources, these self-managed Postman accounts now break that.

• Traditional attacks (phishing, credential stuffing, etc.) against Postman accounts will now likely result in exposure of production secrets.

• As Okta’s recent breach demonstrates, attackers do go after companies that store authentication material to abuse them and replay them against their original targets.

In addition to these kind of issues, Postman is also heading down a path of being a social network for API requests. If you thought people accidentally checking creds into GitHub was a problem, wait until attackers discover the treasure trove that is Postman.

Postman has received an enormous amout of feedback about the security risks of this approach, but has opted to not make any changes to account for them. Their security page mentions only the most basic, check-box style of security:

We use cryptographic methods and industry standards to protect customer data in transit between Postman clients, the cloud, and at rest. For example, all communications and data in transit over the internet require the latest version of Transport Layer Security, a cryptographic protocol that provides end-to-end encryption. By default, encryption is also enabled on all our services that contain data at rest.

Also, your sensitive data at rest is encrypted on the server side before storage using AES-256-GCM. The Advanced Encryption Standard with Galois Counter Mode (AES-GCM) provides authenticated encryption, which ensures data confidentiality and integrity.

This makes Postman not worth the risk given its viable alternatives.

Measured Risk

In a large data set that we sampled:

• 56% of Postman users discovered sensitive credentials when they reviewed their history.

• 30% of those were still valid, which we then had to rotate.

• The other 70% were valid at some point, so would have represented spillage if an attacker had active access to either the user’s account or Postman infrastructure.

• Nobody found any blocking issues preventing them from moving to an alternative client.

Alternatives to Postman

There are several popular alternatives to Postman:

• Insomia. While Insomnia does require an account, they have explicitly implemented features (such as end-to-end encryption) to ensure that their servers never see any sensitive information. If even this amount of connectivity makes you nervous, there is a fork of Insomnia that removes these features: Insomnium.

• Bruno. Also very popular, and offline only.

• Visual Studio (including rich support for secrets), PowerShell’s Invoke-RestMethod, Curl, etc.

Insomnia and Bruno support import from Postman.

Eliminating Postman in your Company

Here is a rough playbook for how you can eliminate Postman in your company. Your mileage may vary, of course.

1. Determine your population of Postman users. We were able to get this list through endpoint URL usage data of users connecting to https://identity.getpostman.com.

2. Instruct these users to:

   Log in (or open) Postman, go the History tab.

   Review any entries with an “Authorization” header, or other sensitive headers. Rotate any credentials associated with any of these that have been saved.

   Review any entries that use URL-based authorization (such as SAS keys for Azure Storage, pre-signed AWS URLs, web hooks, etc.). Rotate any credentials associated with any of those that have been saved.

   After remediation, clear your Postman history and close your account.

   Explore Insomnia, Insomnia, or Bruno as alternative clients.

3. Record their completion in a survey form. We used an Office Form with the following questions:

   1. I have reviewed my Postman history. Regarding sensitive material:

      1. The sensitive credentials / secrets have already expired

      2. I have rotated the sensitive credentials / secrets

      3. I am in the process of rotating the sensitive credentials / secrets

      4. There is sensitive material but I am unsure of the right next steps. I have reached out to [contact]

      5. There was no sensitive material

   2. I have discontinued use of Postman Cloud

      1. Yes, and have found an alternative

      2. Yes, will search for an alternative as needed

      3. No, I am blocked and have reached out to [contact]

4. Use whatever process you have in your company or organization (including escalations, CCing managers, directors, etc.) to burn down the list of employees that have used Postman but not responded to the survey. Of course, actively support those reaching out.

Automating History Analysis

Ideally, you could automate step 3.1 above by running a secrets analysis tool like CredScan on a directory of content. Unfortunately, we were not able to find a reasonable path to automate history analysis.

While Postman does support a feature to export your data, this export is only of collections and similar configurations. It would not export history. Even their GDPR export does not include history.

Additionally, the local and web clients use an undocumented and complicated websocket protocol to interact with the Postman service itself, which would have turned into a pretty extensive reverse engineering and software engineering exercise.