The Postman Variable Mistake That Leaks Tokens (and the 5-Scope Model That Prevents It)

Postman environment variables have two value fields: initial values synced to Postman's servers and current values stored locally on the user's machine. The classic mistake occurs when someone pastes a Bearer token into the initial value during testing, and it syncs to others without realizing it. To prevent this, Postman uses a five-scope system that determines variable resolution order, with local scope winning over global.

The scopes, in order of precedence, are local, environment, collection, global, and finally vault for the most sensitive data.

The key to preventing leaks is maintaining consistent variable names across environments while allowing different values for each stage (Staging, Production, CI). This allows switching between environments with a single click and eliminates the need to edit requests for each deployment. Secrets should only be stored in current values or Postman Vault, with the type set to "secret" for added protection. For truly sensitive data, using Postman Vault ensures the value is encrypted locally and never synced.

CI environments should not contain secrets, as exported environment JSON files with plain-text values should be sanitized before committing. The Postman Console helps debug issues by displaying resolved variables in orange and unresolved ones in red, with the Console showing every request as it's sent. Following these guidelines helps avoid "works on my machine" problems and token leaks in Postman collections.