Your Postman environment is a secret store: the public leak path
A public Postman workspace leaks every API key and token developers embedded in it. The blast radius is the contents of the environment, not the tool. Here is how to contain it.
A Postman workspace, collection, or environment left public exposes the secrets developers embedded in it, and those keys still work against the real backends.
How the attack works
A team workspace is found indexed publicly, with environments holding live values for variables named like apiKey and bearerToken. An external client pulls the collection and environment and extracts the embedded secrets. One of those leaked keys is then presented to the production backend, authenticating as the service, and the backend serves records to it. The exposure happened in a developer tool, but the harm lands on production data. In ATT&CK terms this is T1552, Unsecured Credentials, followed by T1078, Valid Accounts, as the leaked key is reused against the real API.
Why it works
The leaked environment is effectively a secret store. Developers stash live keys directly in shared environments because it is convenient, and the workspace visibility was set to public, so the contents went public with it. The incident is not really about Postman at all. It is about every credential the environment happened to hold, and each of those keys still authenticates against the real service that issued it.
How to fix it
The key insight is that making the workspace private does nothing to keys the attacker already copied. You must rotate every exposed secret at its real backend so the copied values stop working, then set the workspace to private to prevent re-exposure. Deleting the workspace or changing the developer’s Postman password leaves the copied keys valid. For the class fix, keep secrets out of shared environments by using a secrets manager or local-only variables, default workspaces to private, and scan continuously for embedded credentials and public visibility. Scope real activity by correlating each exposed key against the backend API access logs over the window.
Practice it
We built this as a GraphLattice Range scenario so teams can rehearse the harvest, the rotate-at-the-backend containment, and the reasoning that obligations follow what the keys reached, not where they leaked.