Introducing the Secret Variable Type in Postman
In Postman, variables enable you with data reusability and also foster collaboration when developing and testing API requests. Variables are often used to store sensitive information such as API credentials that are needed in the authentication and authorization of API requests.
With the latest Postman release, we want to empower you to better manage your API secrets, passwords, tokens, and keys. While supporting greater collaboration, this will also help you as an API producer in avoiding vulnerabilities resulting from accidentally or mistakenly sharing credentials with an unknown third party.
Variable types
We are very excited to announce that along with variable names and values, you will now be able to indicate variable types in environments and globals. The two types we are now supporting with this release are “default” and “secret.”
Users with editor access will be able to create new variables and mark the type on existing variables in environments and globals. If you don’t specify the variable type, Postman will set it as a ‘default’ type and you will be able to use it the same way as you have already been using it. Values of default type variable will be visible in plaintext on the screen.
We are glad to announce that in the future, we plan to extend support for more types to supercharge your variables even further.
Secret variable type and masking
The secret variable type will enable masking of the initial and current values. Today, when you use variables to store credentials, the values can be seen in plain text on the screen by you and others. With this update, we address vulnerabilities resulting from mistakenly sharing your tokens and secrets to an unintended audience while screen sharing or livestreaming. Masking your sensitive data will also help you avoid threats such as over-the-shoulder attacks.
As a comprehensive API platform meant to foster collaboration, we also want to make sure security remains tight amongst users during collaboration. So, once you set a variable as a secret type, we will mask it for all workspace members. Changing the type from secret to default will result in removing masking on the values for all workspace members.
Creating and converting a variable to a secret type is available to any user who has edit rights on the environment and globals. Moreover, workspace members will also be able to view the value by toggling the eye icon.
Postman has long been committed to securing your data by encrypting and storing all your environment information. With this update, we are taking it a step further so that your data remains safe while you and your team are more productive.
Learn more about using sensitive information in variables here and check out our blog post on best practices while working with variables. Learn more about variable types on our Learning Center.
Great feature.
Please add support for external vault like Azure keyvault.
I think I have missed something here.
I have a login endpoint in my collection, with a password stored in a secret variable in the current environment. That’s great, because I am not sharing that password with the rest of my team.
BUT when I use the postman documenter, the password is displayed to the whole world in clear text, rather than ‘***********’. Isn’t that the wrong way round? How do I make the documenter hide the password to the public?
Second endpoint here: https://documenter.getpostman.com/view/1457045/UVC9h5Lx#9762dc37-8fb9-4663-9b1c-d6142a62c323
Hi David, Please contact our support team at https://www.postman.com/support, and they’ll be glad to help you!
I can’t find where to make a variable “secret type” in the UI. Please elaborate.
Hi Ben, please use the ‘type’ column on the selected environment.
Feel free to check the animation attached to the blog above or visit our learning center.
This is an excellent feature.
Question though. Can the type be set via script?
Hi Cyril, thanks for your feedback.
Currently, setting type via script is not being supported.
However, we are tracking this feature request here
Feel free to discuss your use case further on this ticket.
This is a great future only for the Postman UI. when I export the environment file its showing values as plaintext in .postman_environment.json
Example
{
“key”: “ClientSecret”,
“value”: “Actual Client Secret value in Plain Text”,
“type”: “secret”,
“enabled”: true
},
This should have been done long back, almost when variables were introduced. Still collection level variables have no secrecy.
“Secret variable type and masking”, if we have export these kind of files then what will be value in the exported file it is still masking values
When I create variable using javascript, this variable is persisted.
How can I (a) prevent this persistence or (b) mark this variable as secret?
Yeah, I think you guys missed a fundamental, here. If users can view the secret (in any capacity), then all you’re protecting against is screen monitoring and people standing behind the user while they work.
It does not actually allow people to add real secrets to Postman because every Postman user now has access to the secret.
i.e. This “secret” functionality you’ve added doesn’t actually address the problem. Please read some articles/docs about secret management and do something better; we really need functionality that addresses this.
One idea might be to store the secret elsewhere and only store a reference to the secret within the areas that users can access. Then, proxy requests that contain secrets through a Postman server that injects the secrets.
Obviously that solution creates other concerns, but, it would be a step in the right direction.
This isn’t really secret at all – the variables are not encrypted and are stored on postman’s cloud infrastructure. Is there anyway not to send a company’s secrets to postman if you are signed in?
Great news!
Though when I use the variable in my request, while I edit it, the tooltip pops up saying “Current value is …” and it shows the password. And the password is still very much accessible from everywhere like any other variable.
You are definitely moving in the right direction, but long way to go still.
Nice option, but looks like it won’t work for a Bearer token (auth) – I get 401, unauthorized. Maybe because I am not using a workspace, but scratchpad instead?
PS Please mind that using workspace instead of scratchpad might become a security issue if someone gets access to the cloud data, so I would avoid putting in a sensitive information in a workspace.