Every API gets breached the same way. The attacker does not break the API. The API breaks itself, and the developer who built it learns about it from the breach disclosure. The pattern has a name now, the Postman problem, named for the popular API client that has become the developer’s favorite way to test the production environment, the place where the production credentials end up living in the developer’s laptop. The honest framing matters here, because the Postman problem is not the developer’s fault. The tooling rewards the bad practice, the workflow incentivises the export, the security team that built the production API never sees the developer’s laptop.
What follows runs as the working version of the field guide. The shorter version is what the security team and the developer team should both read.
How the problem got the name
Three things, in roughly that order of how much each one contributes. The first runs as the collection, where the developer opens the Postman client, the developer creates a collection, the developer adds the production API endpoint, the developer pastes the API key, the access token, the customer scoped credential, the credential sits in the collection, the credential persists across the developer sessions. The second runs as the environment, where the developer creates the environment (the production, the staging, the dev), the environment holds the variable, the variable holds the credential, the credential persists in the environment file, the environment file sits in the Postman cloud sync. The third runs as the export, where the developer shares the collection with the team, the developer exports the environment, the developer attaches the export to the Slack message, the developer commits the export to the repository, the credential leaks in the export, the leak happens in the same way the developer has been doing it for five years.
What actually leaks
Three categories, in roughly that order of how much each one hurts. The first runs as the production API key, where the credential grants the production access, the credential grants the read access, the credential grants the write access, the credential the developer has been using to test the production API. The second runs as the OAuth refresh token, where the token grants the long lived access, the token grants the user scope, the token grants the data the user can see, the token that the developer has been using to test the user facing feature. The third runs as the customer scoped credential, where the credential impersonates the customer, the credential reads the customer data, the credential writes the customer data, the credential the developer has been using to test the customer integration. The three categories together cover what the Postman export actually leaks.
How to fix it without breaking the workflow
Three moves if you are the security team that wants to fix the Postman problem without breaking the developer workflow. Use the secret manager integration, because the Postman integration with the secret manager (the HashiCorp Vault, the AWS Secrets Manager, the Azure Key Vault) pulls the credential at request time, the credential never sits in the collection, the developer keeps the workflow the developer likes, the security team gets the credential out of the export. The integration costs a sprint to set up and saves the breach disclosure. Use the ephemeral credential, because the credential that the developer issues for the test session, that expires in 24 hours, that scopes to the test environment, the ephemeral credential cannot leak what the credential does not have, the ephemeral credential that the platform team issues on demand serves as the credential the production system never sees. Audit the export, because the export that the developer shares, the export that lands in the repository, the export that the secret scanner should find, the audit that runs on every commit, the export that the scanner catches serves as the export the breach will not. The security team that ships the integration, uses the ephemeral credential, and audits the export serves as the security team that fixes the Postman problem without breaking the developer workflow.
The bottom line
The Postman problem in 2026 sits as the credential leak the developer does not know about. The secret manager integration, the ephemeral credential, the export audit, those three work. The developer who keeps using the collection with the credential in it serves as the developer who is one export away from the breach disclosure. The security team that ships the three moves serves as the team that closes the leak without breaking the workflow.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
