Does Postman Pro allow you to disable syncing of environments? If not is there an alternate method to keeping sensitive data local while still using a team workspace?
Turning sync off isn’t possible but we added the notion of Sessions in a previous release that enables you to store sensitive information (API keys, tokens, etc) as environment variables that aren’t synced.
- Sessions FAQ – Sessions FAQ | Postman Blog
- The RFC – https://community.postman.com/t/sessions-in-postman/1925
tl;dr – Store your sensitive data within the Current Values field in the environment template so that it isn’t synced.
1 Like
Thanks for the response. Can you clarify a couple of things?
Is the CURRENT VALUE not synced?
Should I avoid putting sensitive information in INITIAL VALUE?
Per company policy these values can’t be stored anywhere that is backed up the the cloud. Ideally we would have our environments stored only locally, and a team workspace that is synced.
Thank you.
@Kristian Bumping an old thread. Data in Current Value is not synced to Postman’s servers. It is a common security practice to store passwords/keys/tokens in Current Value, and use the Initial Value column as a placeholder.
2 Likes
As an ignorant user: Can we still get a switch to disable that, please?
Thanks.
5 Likes
Our company (1000 employees) disallow postman because there is no option to keep the information safe. Postman should have an option to disable syncing data like api keys or other secret information.
7 Likes
We came very close to this as well. We had to fight pretty hard and demo a bunch of workarounds to make security comfortable enough to allow us to continue using it for now.
2 Likes
If the Current Value isn’t synced with Postman’s servers, how is it possible that I see them in https://web.postman.co/workspace ?
2 Likes
This is my company’s recommended usage. But, it’s easy to inadvertently copy a secret in Current Value to Initial Value, whereupon the secret gets synced / breached / leaked.
If postman is to be enterprise-ready it needs a systematic way to prevent secrets from leaving the company.
2 Likes
This was such a horrible policy. It is cruel to developers. There is zero need for Postman to hold onto proprietary info. It has resulted in many businesses and institutions ordering employees to cease using Postman.
=(
1 Like
I’ve got to ask. Playing devils advocate.
Do you use Github? Or Office 365, or anything in Azure?
I’m not defending Postman here, but most suppliers are moving their wares to the Cloud.
Postman has already advised that both online and offline services doubles the development time. Whether you agree with that decision or not, that is their justification.
Personally, I don’t have a problem with this being hosted in the Postman Cloud.
However, we would need Enterprise licences with a static IP and single sign on, which makes it a bit expensive for our needs, which was working fine by exporting the collections and environments and running from our code repository using Newman.
The data is encrypted at REST and Postman does not have access to our data unless we share the API key or make the collection public.
They also have a feature now that will scan the initial values for known tokens from Microsoft, Google, etc.
If you wanted bolts and braces, you can use the Postman API to scan all collections and environments in a workspace, and retrieve the current values for someone to review on a daily basis.
No, we do not. Unless it is in a private FedRAMP certified cloud.
With V11 of Postman, we have introduced the Postman Vault (Store secrets in your Postman Vault | Postman Learning Center), which allows you to store your sensitive data in an encrypted local vault that is not synced with the Postman Cloud. Also, we have added multiple security features to help prevent accidental exposure of your API credentials.