In April 2024, TruffleHog researchers scanned 40,000 Postman workspaces and found 1,689 live credentials spanning 183 different secret types. 32% of those credentials were in variables developers had explicitly marked as "secret." That designation has no effect on synchronization with Postman Cloud.
The "secret" type exists at the rendering layer, not the transport layer. Masking a value with asterisks on-screen does not alter the behavior of the Initial value field. That field syncs to Postman's servers regardless of the type assigned to the variable.
GitHub tokens, AWS keys, Slack tokens, and admin credentials sit indexed in Postman's public API. Anyone who knows where to search finds them without authentication. Entire teams use Postman as a collaboration tool without knowing they are operating an exposed credential repository.
Postman's Data Model Creates Three Distinct Exposure Vectors
Postman's hierarchy has three layers: workspace, collection, and environment. Making a workspace public automatically exposes every nested collection and environment. A developer who shares a workspace for documentation also exposes every environment created within that workspace.
The Initial value field syncs to Postman Cloud and becomes visible to anyone with workspace access. The Current value field stays local on the developer's machine. The UI presents both fields side by side as equivalent, without indicating that their security properties are opposite.
Public workspaces are accessible via the Postman API without authentication. The endpoint GET /workspaces?type=public returns the full list and requires no token. This makes workspace enumeration a simple read operation with no technical access barriers.
The "secret" Variable Type Does Not Protect Data from Cloud Sync
The Initial value of a "secret"-typed variable reaches Postman's servers exactly like a "default" variable. Sync does not differentiate between the two types because "secret" was designed for display control, not access control. Postman's server has no mechanism to determine which data should or should not sync based on this designation.
TruffleHog's April 2024 research confirmed this empirically: 32% of the 1,689 live credentials found were in variables carrying the "secret" type. Developers mark a variable as secret and assume the data is protected. The UI offers no contradiction, creating a security gap that persists as long as the workspace is public.
GitHub issues and developer forums show widespread confusion about this distinction. The documentation describes the "secret" type as hiding values from collaborators, which developers interpret as security isolation. The actual behavior is display masking only, with no effect on what Postman stores or syncs server-side.
Postman's documentation recommends Vault and the UI displays a warning when setting Initial Values in public workspaces. The warning appears after the value is already typed, and teams routinely dismiss it without reading.
The confirmed live credentials span AWS, GCP, OpenAI, and GitHub among others. TruffleHog validates each credential against the provider's real API before classifying it as live. This confirms that the tokens found are functional at time of discovery, not just pattern matches against known formats.
The Workflow That Creates the Exposure
The most common path starts during API integration development. A developer creates a Postman collection, adds environment variables with real tokens to test against staging, and shares the workspace with the team. The workspace gets made public for onboarding or documentation, without the environment variables being reviewed first.
The second common vector is exporting environments to Git repositories. The .postman_environment.json file aggregates every key-value pair from an environment into a single JSON structure. When that file lands in a GitHub repository, it concentrates months of credential additions into a single target. Staging and production tokens appear in the same file, often with distinct values for each environment.
A third vector: forks of public collections. RedHunt Labs found that 16% of public forks of OpenAI collections and 20% of Pynt collection forks contained live credentials. When a developer forks a collection for their own use, the associated environments carry the tokens along.
There is also the shared workspace case with external partners or contractors. Access gets revoked when the engagement ends. Credentials stored in environments persist in Postman Cloud sync as long as the workspace exists.
The Scale of Exposure Across Three Independent Studies
TruffleHog's April 2024 study used two separate samples. The first: a targeted 40,000-workspace corpus built by searching naming patterns common in developer tooling. That scan found 1,689 live credentials. The second: a random 6,500-workspace control sample, which measured a 1.83% base leak rate. Extrapolated to the 200,000+ workspaces Postman indexes publicly, the estimate reaches 3,660 workspaces with live credentials today.
The 1,689 confirmed credentials span AWS, GCP, OpenAI, GitHub, and 179 additional providers.
RedHunt Labs, in Wave 14 of Project Resonance, scanned 200,000 Postman environments and extracted 84,260 secrets. Among them: 70,875 JWTs, 5,500 bearer tokens, 555 GitHub access tokens, and 521 Azure subscription keys. In December 2024, CloudSEK identified 30,000+ public workspaces with exposed sensitive data.
Primary sources for Wave 14: redhunt.net/research/project-resonance (RedHunt Labs). CloudSEK figures: cloudsek.com/blog. TruffleHog corpus: trufflesecurity.com/blog.
Okta IAM credentials from an athletic apparel company granted internal API access organization-wide, per CloudSEK's December 2024 report. ZenDesk admin credentials from a healthcare firm gave full access to the support portal. GitHub API credentials appeared in 5,924 instances; Slack in 5,552; Salesforce in 4,206.
The composition of exposed secrets reveals what makes this vector particularly damaging: most are not database passwords but SaaS tokens. A single compromised workspace can unlock an organization's entire tooling stack, not just one isolated service. The attacker moves laterally through Slack, Salesforce, and Stripe using a single Postman environment file.
How Attackers Enumerate Workspaces with Credentials
Postman's public API at postman.com/search indexes workspace and collection metadata. A search for api_key with scope=public returns structured results without authentication. TruffleHog researchers built the 40,000-workspace corpus using targeted searches against naming patterns common in engineering teams.
The GitHub dork filename:.postman_environment.json returns exported environment files from public and private repositories. These files typically contain staging and production variable sets in the same JSON. That makes them higher-yield targets per query than searching application source code.
For programmatic scanning, TruffleHog includes a dedicated Postman scanner:
# TruffleHog v3.x — verify current flag names at github.com/trufflesecurity/trufflehog
trufflehog postman --workspace-id <workspace_id> --token <postman_api_token>
The scanner validates each credential found against the provider's real API. The output is not a list of pattern matches but an inventory of tokens that work at execution time.
Auditing Your Postman Exposure
The audit covers three surfaces: public workspaces your organization owns, collections exported to GitHub, and forks of public collections created by team members. To list public workspaces via the Postman API:
curl -H "X-Api-Key: $POSTMAN_API_KEY" \
"https://api.getpostman.com/workspaces?type=public"
The MAGO Intel tool (intel.mago.team) scans Postman's public search API for workspaces associated with a target organization and flags environments containing live credential patterns.
For GitHub, the dork filename:.postman_environment.json org:<yourorg> returns exported environment files from organization repositories. Any file found should be treated as compromised until a manual audit confirms otherwise.
This scan should be part of a regular security review cycle, not a one-time action. New team members create workspaces and export environments continuously. Exposure grows with headcount.
Postman Vault Closes the Sync Vector
Postman Vault Local is available on all plans, including free (as of Q4 2024; verify current availability at postman.com/pricing), and does not sync to Postman Cloud. Secrets referenced with {{vault:secret-name}} are encrypted locally with AES-256. The Shared Vault, available on Solo, Team, and Enterprise plans, syncs with team access controls.
For CI/CD pipelines, Newman accepts credentials via the --env-var flag at execution time, without storing anything in the collection. This approach injects values at runtime from the CI system's environment variables. The Vault and runtime injection solve the problem at the source: the Initial value field never receives a real credential.
For existing GitHub repositories, add to .gitignore:
*.postman_environment.json
*environment*.json
*.postman_globals.json
Enterprise plan customers access native integrations with AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, and 1Password. These integrations replace the Initial value field with a reference to the external vault, eliminating local credential storage in Postman.
Run trufflehog postman against your workspace today. If you find live credentials, rotate before communicating the incident. Postman's search index updates faster than most incident response timelines.
Top comments (0)