How to securely deploy Postman at scale, part 2: information management

Whether you’re a team of five or 500, keeping data secure is a top priority. In Part 1 of this blog post series, we covered user-management features that teams can implement to help keep their Postman instance secure. In this installment, we’ll cover more information-focused security features. We’ll look at how a team of any size can incorporate Postman’s security features as part of a developer workflow, then take a broader view and look into administrative-level features that can help larger organizations secure their Postman deployment.

Best practices for developer security

In the same way that you may have security best practices set up for your other developer tools like version control (keeping proprietary repositories private, not committing API keys to a codebase, keeping an eye out for GitHub security alerts, etc), similar considerations should be given to your Postman workflows. Though these version-control interventions may now seem second nature to some, there first had to be an understanding of the underlying technology before it was decided how best to work with it. The same goes for Postman: the features you utilize (or don’t) can play a role in keeping data secure. Let’s start with the steps everyone can take to tighten up their workflows.

Using variables and sessions responsibly

If you’ve developed with Postman for any length of time, you are probably familiar with the concept of variables, at the collection, environment, and global levels, and their two-column “initial value” and “current value” layout. To fully utilize the variables feature, it’s vital that your team understands the function of both columns. Initial values will have their contents synced to the cloud, and shared with anyone else who can view the workspace. Current values, or “sessions,” allow you to work with variables without affecting others—these values are local only to your instance of Postman and will not be shared to anyone else’s variable view or overwrite their own current values. This makes the CURRENT VALUE column the best choice when using sensitive information inside of variables, like API keys, passwords, etc. If you are setting up a collection or environment and expecting other users to use sessions to avoid leaking information, it can also be helpful to provide a placeholder value in the initial value column, like your-api-key, or <password>.

Secret variables

In the age of remote work, sometimes even thoughtful usage of current and initial values may not be enough to avoid broadcasting your API secrets on screen. When you’re sharing your screen with coworkers to demo your great new API endpoint or debugging on a livestream, it can be hard to avoid exposing secrets like API keys and passwords that are stored as variables. Postman’s answer to this is “secret” variables, allowing you to mask values stored in environment and global variables. To make a variable secret, switch its type from “default” to “secret” in the Type column (right next to initial and current values). If you are using secret variables in a shared workspace, note that you can use role management to prevent other teammates from toggling the value back to being visible, but these values are not encrypted and may show up for them in other places in the postman UI, like the console or collection runner detail views.

Security alerts for API producers and consumers

Have you ever been here? You’re testing out an API, plugging your plaintext API Key in different requests to try and get something working, and, without thinking, you saved the request, exposing your key to everyone who has access to the collection. Maybe it even took days before you realized what you had done. While hopefully your teammates kindly forget they ever saw it, it’s not great practice and can lead to some sticky situations if the collection is public-facing.

To try and prevent these sorts of situations, Postman has built-in token scanner alerts, sending alerts through Slack, email, and in-app notifications to get your attention when the app suspects you’ve saved a request with a sensitive token value. The default list of values that will trigger alerts include commonly-used API key patterns, like AirTable, GitHub, etc., but Enterprise users also have the ability to define their own custom alerts. If you do see one of these alerts pop up, before dismissing it, be sure to track down the exposed value and delete your token or API key immediately.

A similar feature also now exists for GitHub security scans: if you accidentally publish a Postman API key to a public GitHub repository, Postman will send you an alert via email, Slack, and/or in-app notification depending on your settings. We, again, recommend considering the key compromised and deleting it immediately.

Monitoring and reacting to security threats

While teams are getting their workflows in place to ensure better practices for keeping information secure, account admins should take some time to explore the security features available for monitoring how team members are using Postman—and create a plan for who will be responsible for each area.

Managing public elements

Keeping a small circle of trusted users as Editors and enforcing an approval process is the first step in establishing a secure Postman environment, but familiarizing yourself with how information on Postman can be made public, either intentionally or unintentionally, and how to mitigate it is vital.

The interfaces through which information in your team’s instance could become public include: public workspaces, collection documentation, public JSON collection links, and public mock servers. Let’s take a look at the first three and how to prevent unintentional sharing of information:

1. Publishing a public workspace: Toggling a workspace’s visibility to “Public” will allow anyone on the platform to see it.

2. Publishing collection documentation: Publishing a collection will generate a single, customizable page with all of the information from your collection displayed as documentation, shareable via URL. Even if the collection you publish is in a personal, team, or private workspace, it’s important to keep in mind that the page is discoverable and the link is public.

3. Generating public JSON collection links: Postman allows the sharing of collections in a few different ways, by exporting the collection as a file, generating a Run in Postman button, or generating a public link that will display the collection’s JSON. Similar to the collection documentation visibility, any JSON links generated for collections in personal, private, or team workspaces will be visible to whoever has access to the link.

All three of these interfaces can be managed via the “Manage Public Elements” page available on Postman Enterprise plans. From here, a user assigned to the Community Manager role can keep tabs of what has already been published, prevent the generation of new JSON collection links, or add an approval requirement for workspaces other team members want to make public.

Now let’s look at public mock servers.

4. Creating mock servers: Creating a mock server, even in a personal, private, or team workspace, generates a URL that is public and can be used by anyone with access.

Since mock servers will only return information that has been added as a saved example on a request, it is good practice to make these responses generic, with as little sensitive or identifying information as possible. Still, for highly sensitive APIs, another layer of protection should be added by toggling your mock server setting to Private. This will require anyone using your mock server to use a Postman API key belonging to your Postman team.

Security reports

Earlier, we mentioned how the token scanner will send alerts if a sensitive string is saved to a public request. This is great for helping developers keep sensitive information from going public in the moment, but it may be helpful to get a broader overview of these incidents to help identify patterns of these security incidents. For Postman Enterprise users, the Security section of the Reporting tab gives a broad overview of what types of keys have been exposed over the last thirty days. By looking at which service’s keys were exposed and in what context, teams can start to strategize better workflows to help keep tokens secure.

Audit logs and Audit Log API

As an administrator of the account, we recommend periodically reviewing the Audit Logs page in the UI, where you can see various events related to users, team, and billing, and filter based on event or actor, just to keep tabs on what is being set up in your instance. For those with a security information and event management (SIEM) setup, the same information is available over API, allowing you to plug into your current threat management system.

Automating governance

The final part in keeping information secure are the organization-wide steps you can take to enforce and automate security measures. In the previous post we covered secure sign-on (SSO) as a way to keep your Postman instance secure from the “people side,” but there are a few one-time Postman platform setup tasks you can implement to keep your data secure as well.

API key expiry

We’ve covered reactive API key alerts and what to do if one gets exposed, but preventative measures can be taken into this process as well. Postman users can set their generated API keys to expire after 30, 60, or 180 days of inactivity. Because these API keys effectively give access to all of your Postman data, we recommend the shortest feasible expiration period your organization can handle. Even with the best of practices and intentions, it is best to not leave any keys active for long periods of inactivity. Do keep in mind, though, that your team will need to have a plan in place for swapping keys out at expiration time in CI/CD pipelines and any other places where they may be used.

Enterprise application management

For larger organizations or those with strict security standards, control and insight are needed when installing any third-party apps. The Postman Enterprise app plays nicely with MSI and PKG installers. If your organization is already installing apps via controlled deployment, we recommend adding Postman to your list of managed business apps. Having all of your users on an organization-controlled app makes for a smoother installation process, and ensures everyone is using the same version of Postman.

A final security checklist

Now that you’ve read our recommendations for securely setting up Postman, we’ve put together a checklist with everything covered in this two-part series on security. If your current setup doesn’t check all of the boxes, picking one or two tasks to focus on implementing is a good next step in amping up your API security practices.

For everyone

• Do you use “secret” variables to obscure sensitive values when sharing your screen or working in a crowded environment?
• Does your team keep sensitive values to the “current value” of variables in order to prevent sharing of sensitive information?
• Do you have team-level roles set up, with a select group of Admins?
• Does your team have a plan in place for when the Token Scanner alerts of leaked keys?
• Does your team use an expiry period for Postman API keys and have a plan for replacing keys after their expiration?
• Does your team monitor active team invite links and deactivate them if not needed?

For Enterprise users

• Does your team use access controls at the workspace or element level to restrict who can edit collections/APIs?
• Do you use user groups to easily check who has access to which resources?
• Do you have a Super Admin, Community Manager, and Network Manager role assigned?
• Does your Community Manager check the “Manage Public Elements” page at regular intervals to ensure that only authorized information is shared publicly?
• Do you have SSO set up?
• Do you have SCIM set up to help provision, edit, and deprovision users?
• Do you have Domain Capture set up to ensure everyone in your organization is working with internal APIs in a secure environment?
• Does your team utilize the Postman Enterprise app if you are using a managed deployment of other business applications?
• Do you have a custom token alert set for your proprietary and/or third-party token?
• Do you have integrated audit logs in the Security Information and Event Management (SIEM) tool if you use any?
• Do you periodically check Security Reports?

This post is by Postman Technical Enablement Architect Carson Hunter, Postman Senior Engineering Manager Suhas Gaikwad, and Postman Security Engineer II Ronak Odhaviya.