Since you people close every threat concerning the forced sign in. Besides being the guy who needs to test the APIs of our company, I am the guy who write our security guidelines and policies. There is no way I would allow a tool to sync confidential data as API-Keys or even the requests themself to any cloud.
I am just here to say thank you for force updating the app without my consent and scrapping the tests I have build over the last couple of month. Now I have the headache to find new tool mid release.
Scratchpad was a really good tool you broke intentionally without any need or purpose, away from collecting user data without consent.
You can Export all your data using the ⚙️ > Settings > Data option, this can be done from the Lightweight API Client. However, to Import this you would need to be signed in.
There is an FAQs section on the announcement blog which provides information about our security process and how we handle data.
This also provides a link to our Security and Trust Portal where you can request to download the latest SOC 2 report, SOC 3 report, CSA STAR and Security Features Report documents.
Here is the link to the Security and Trust FAQs which provides some more granular information.
In terms of the safe practices to follow with your data and credentials when using your Postman account:
Be careful to avoid accidental data exposure when making a Postman element public, such as workspaces, collections, and environments.
We strongly recommend you avoid storing sensitive data anywhere except within Postman environments. Storing variable values only in the Current value field, will ensure that the data is never sync’d.
You should also use environment variables with a secret type to store sensitive data and credentials, including API keys and access tokens.
First of all, I don’t work for Postman and I also complained about the changes for the Collection Runner when they were first implemented.
However, Postman is a company and they are allowed to make changes to their product and us as consumers can vote with our feet.
Postman explained why they were deprecating the scratchpad which was down to the development effort of keeping it in synch with the rest of the code base.
Every time they wanted to make a change for how collections work, they also had to test the scratchpad and it was causing a support overhead, so they made a decision to make a lightweight client for offline use.
I still think this could have been explained a bit better, and the communication likewise.
I not justifying this, but this is Postman justification for why the changes were made. If you really think this is about collecting user data without consent then I’m not sure what else to say to you.
Secrets should be in the current values in Environments. These do not get synced to the cloud, but appreciate its fairly easy for someone to put it in the wrong fields.
Postman has just created a checker for common secrets (API key’s) but I think need to extend it to just all the current values across all collections to a org or team admin.
I also get to define policies within our org, and I’m ok with the security aspects of Postman, but it means an Enterprise license with single sign on, and a static IP address, which means its too expensive for my organisation. I don’t need the CLI as I store everything in our code repository and use Azure Pipelines and Newman for execution.