tl;dr Postman, the popular API testing platform, hosts the largest collection of public APIs. Unfortunately, it’s become one of the largest public sources of leaked secrets. We estimate over 4,000 live credentials are currently leaking publicly on Postman for a variety of popular SaaS and cloud providers.
In this article, we share our research on credential exposure on Postman. Want to scan a Postman workspace with TruffleHog right now? Try our new command:
Q: Where are secrets leaking on Postman?
A: Postman’s Public API Network.
A few years ago, to compete with RapidAPI and others, Postman launched a public network for developers to “share and showcase” their APIs.
Postman users make their private workspaces and collections public for the entire world to use. On the surface, the idea of conveniently sharing API documentation with others sounds great, especially since so many API developers already work out of Postman.
Unfortunately, an unclear UI and ambiguous taxonomy has created an environment where developers are unintentionally leaking thousands of secrets. This has created a significant opportunity for attackers to steal credentials.
Q: What secrets are leaking on Postman?
A: We found live secrets from 183 different SaaS and cloud providers, including AWS, GCP, OpenAI, GitHub, and Postman. The most common type was a sensitive URI.
We used Postman’s search API to create a list of ~40,000 unique workspaces and then scanned each workspace with TruffleHog’s new Postman secret scanner. We discovered 1,689 live, unique credentials, representing 183 different types of secrets.
The most commonly identified secret type was a sensitive URI. Sensitive URIs include secrets like Slack Webhooks. In this research, the most common sensitive URI we found was a URL containing basic auth information. For example, the screenshot below shows a user leaking a shopify credential in their Shopify store’s link.
The other most popular key types were: GitHub Personal Access Tokens, OpenWeather, OpenAI and (unsurprisingly) Postman API Keys.
We also found evidence of many, many more secret types that TruffleHog does not detect. For example, TruffleHog does not currently have an Elastic Cloud detector (feel free to contribute one!). We found thousands of requests referencing Elastic Cloud resources. And many of them appeared to contain live credentials, like the screenshot below.
We also found many instances of QA teams for major multinational companies leaking credentials for internally-developed applications that TruffleHog does not detect out-of-the-box.
As an example, a well-known residential, commercial and industrial technology company leaked their entire production tech stack for a new multi-million dollar product line, including IAM servers, ElasticSearch instances and much more. (Don’t worry! We told them. It’s been removed!)
A Note About our Research Process:
Our research goal was to identify as many live credentials in Postman’s Public API Network as we could. We first built a list of workspaces and then ran each one through TruffleHog’s postman secret scanner.
To create a list of workspaces, we built a list of search terms that referenced specific secrets that TruffleHog could detect, ran each term through Postman’s search API, and then deduplicated the results.
A Big Caveat: Postman limits search results to 200 workspaces, so in many cases, we were only able to obtain a small fraction of the public workspaces that might contain a relevant live credential.
For example, searching the term PayPal shows 1k + results, but we could only access 200 of those.
A Second Caveat, Postman’s search does not look at variable field names or authorization information, which would have produced a highly targeted list. Instead, the search function relies on string matching with higher-level concepts, like Workspace names, which might not indicate the secret hiding inside.
Point being: our total findings represented a subset of the all leaked keys. Next, we attempted to estimate how many total keys have leaked.
Q: How many secrets are leaking on Postman?
A: At least 4,000 live secrets are currently leaking on Postman, but thousands more likely exist.
In our research above, we identified 1,689 live, unique credentials from ~40,000 different workspaces. Postman advertises over 200,000 workspaces on their Public API Network. Considering we sampled less than 20% of the total, it stands to reason that additional keys exist. But our previous research was biased. The goal was to identify as many keys as possible, so we used search terms that corresponded to secrets that TruffleHog could detect.
To fairly estimate the quantity of leaked secrets across Postman’s Public API Network, we created a control group of workspaces using generic search terms that had no relation to specific credential types.
We ended up with ~6,500 control workspaces. We ran three trials. During each trial, we built a random list of 1000 workspaces from the control list (no replacement) and checked each one for secrets using TruffleHog.
The table below shows the results of each trial.
On average 1.833% of the control workspaces leaked 1.31 unique secrets.
Assuming there are exactly 200,000 public workspaces, then we can reasonably expect 3,667 workspaces to leak a secret. Since the average workspace leaks 1.31 unique secrets, we can expect to find 4,804 leaked secrets.
But what about duplicates across workspaces? Using data from our previous research (section above), we found that a secret leaked by a workspace had an 82% chance of being globally unique across the entire dataset.
If we multiply our original estimate of 4,804 by a uniqueness factor of 82%, we arrive at just about 3,939 secrets.
Are there more than 4,000 secrets leaking? 100%.
We claimed that at least 4,000 live secrets are currently leaking on Postman, but thousands more likely exist. Why are we confident that so many more might exist?
We don’t know the exact size of the Public API Network. It just says “200k +”. If that figure is closer to 300,000, then our estimate could be as high as 6,000 secrets.
TruffleHog cannot identify every secret in the world. It only works on 800 secret types. There are thousands of additional SaaS providers on the market and we found evidence of many of them on Postman.
TruffleHog cannot confirm credentials for applications and services that are only reachable on internal networks (unless you run it from within that network). We found evidence of hundreds of thousands of requests referencing internal IP address spaces. For example, searching for the internal “10.10.0.0/16” CIDR range using the search term “http://10.10” revealed close to 200,000 requests.
So, is 4,000 secrets a lot?
Let’s flip the question: is finding a secret on 1.83% of all public workspaces a lot? Yes. From all of the research we’ve done on various other sources, developers seem to be leaking data at a much higher rate on Postman.
Q: Why are secrets leaking on Postman?
A: Forks, confusing UI, and Insufficient Secret Scanning.
Forks
The core purpose of the Public API Network is to “share and showcase” API documentation. To facilitate this, Postman created a “fork” feature, which functions similarly to GitHub’s fork. You can fork a public collection and then use the API documentation on your own.
Unfortunately, many users publicly fork popular collections, such as OpenAI, and then plug their live API keys in to test it out. Anyone can then see that key.
We tracked two popularly forked collections: OpenAI and Pynt (a Python security tool).
We found 16% of all public OpenAI forks contained live credentials and 20% of Pynt forks did.
Unfortunately, while the fork feature is convenient, without proper user education and safe defaults, Postman users will continue to expose their credentials in public forks.
Secret Variable Types
Postman provides users with two types of Environment variables: “default” and “secret”. The term “secret” is extremely misleading.
While users see asterisks blocking the public view of their environment variable, a “secret” variable value is simply masked data. Anyone can unmask it and view the value.
During our research, we found that 32% of all environment variables containing live credentials had the “secret” type marked. Our assumption is that those users believed they were securely storing their variable values, but they were not.
Current Value vs. Initial Value
In the screenshot above, you can see two values for the global environment variable API_KEY: “Initial value” and “Current value”.
Initial values are synced to Postman’s servers and viewable by anyone with access to the workspace, which in the context of the public API network is everyone.
Current values are local to the user’s Postman client and not stored remotely, nor viewable by the whole world.
Unfortunately, the terms “Initial value” and “Current value” are extremely confusing and do not properly convey the security implications of key storage.
And that’s not just our opinion, we found hundreds of leaked keys sitting in “Initial value” fields. Additionally, there are endless threads on Postman’s GitHub support page about fixing the default behavior associated with storing environment values in these fields.
Insufficient Secret Scanning
Postman offers a basic secret scanner. And it does detect some key types. However, the default behavior is to alert users after publishing that they’ve leaked a secret.
Undoubtedly, this provides some help to users. However, the default behavior should force users to accept the risk of making a workspace public that contains known-secrets. A small pop-up on the bottom of the screen can be easily disregarded.
