Summary 

• The TRIAD Team, leveraging CloudSEK’s XVigil, has identified significant risks stemming from the improper use of Postman workspaces, a popular cloud based API development and testing platform.
• In this blog, we will present some of the interesting yet critical incidents that could lead to massive data breaches of customer PIIs, abuse of legitimate services owned by organizations through takeovers, launching malicious campaigns, and more.
• Our year-long investigation uncovered that more than 30,000 publicly accessible Postman workspaces were disclosing sensitive information. In most instances, these collections included access tokens, refresh tokens, third-party API keys, and even test or demo user data from organizations of various sizes and across different industries. Although many instances of leaked third-party API keys and tokens can be traced back to inadequate permissions or limitations within the API architecture preventing proper owner identification, the ultimate sources often remain unknown.
• Most of the identified incidents were attributed and  responsibly reported to the respective organizations.

‍

‍

Sensitive Data Leaks in Postman: What You Need to Know

In the fast-paced world of API development and testing, Postman has emerged as a go-to tool for developers and organizations. Its ease of use, versatility, and collaborative features make it indispensable. However, with great power comes great responsibility—and risks. Postman environments often house sensitive data, from API keys and tokens to confidential business logic, making it a potential goldmine for malicious actors when mishandled.
Sensitive information like API keys, documentation, credentials, and tokens often ends up exposed through Postman collections, creating serious security vulnerabilities. Using CloudSEK’s XVigil, we uncovered multiple instances of sensitive data being unintentionally leaked, underscoring the critical need for better security practices and awareness.

Case Studies: From Various Reported Incidents

Leaking of various Business and Internal Data via Okta IAM API

One of the leading organizations in the Athletic Apparel and Footwear industry could have been compromised due to one of the private Postman workspace being leaked by a 3rd party vendor. The requests in the workspace are being made to the Okta IAM of the organization along with the valid credentials and access token. With that access any threat actor could have accessed other internal APIs of that brand mentioned in the Postman Workspace. Due to these accesses, malicious actors could exfiltrate various invoices, trade contents, attributes, shipment details along with various commercial data. 

‍

‍

Impact Analysis:

• The impact of an unauthorized user gaining access to a company's internal APIs would be far-reaching and significant. Threat actors could not only manipulate records and take unauthorized actions—resulting in financial and reputational harm to the organization—but also gain access to confidential data. In extreme cases, the entire company database could be at risk.
• Furthermore, it could be difficult to identify unauthorized modifications or actions unless proper tracking and monitoring systems are in place. All of this would have a direct effect on the security and reliability of the company, its customers, and its employees. 

‍

Leaking of various Healthcare customer and Internal Data via Leaked Zendesk credentials

A major healthcare firm could have succumbed to a major data leak leaking customer information as well as access to the support portal with full administrator privileges due to a public Postman workspace that was discovered leaking highly sensitive information, including active ZenDesk admin credentials. This kind of exposure is a ticking time bomb, potentially opening the door to customer data breaches and unauthorised access to the organisation’s ZenDesk support portal—risks that could severely impact both reputation and finances.

‍

‍

The exposed ZenDesk credentials, still active, could allow malicious actors to log into the support portal with full admin privileges. This means they could perform critical actions, like creating or modifying Community Articles in the organization’s name, further amplifying the potential damage.

‍

‍

‍

Leaked Razorpay API Credentials.

During our investigation, we came across multiple instances of Razorpay API keys being accidentally exposed in publicly shared Postman workspaces. These keys, designed to enable secure communication with Razorpay’s API, were left unprotected, making them vulnerable to unauthorized access.

This kind of oversight could easily allow threat actors to exploit the exposed keys, potentially leading to financial fraud or misuse of payment systems. It’s a stark reminder of the importance of securing sensitive credentials, especially in collaborative environments.

‍

‍

Leaked API keys can have devastating consequences, including unauthorized transactions that lead to financial losses, breaches exposing sensitive customer data, and significant reputational damage as trust and compliance take a hit. Businesses may also face operational disruptions, as revoking and regenerating keys while addressing the fallout from misuse can interrupt normal workflows.

‍

‍

‍

Leaked Refresh Token with Session Secret and API Call

We discovered a serious leak in a public Postman workspace where a refresh token and session secret of a major CRM software were exposed. To make matters worse, the API endpoint for generating access tokens was also included, allowing unauthorized users to potentially exploit the entire token lifecycle.

‍

‍

The leak of the refresh token and session secret opens the door to serious risks. Attackers could use them to generate valid access tokens, giving them unauthorized access to sensitive APIs. This not only puts data at risk but also allows for session hijacking, where user sessions can be exploited for data theft or service misuse. Worse yet, if other details are also exposed, attackers could escalate their access, compromise systems further, or even impersonate legitimate users, making the impact even more severe.

‍

‍

‍

Leaked NewRelic API Credentials

The requests in the workspace are being made to the New Relic API (Logs Monitoring and Analytics Software) of a big software company along with the valid API Key. Threat Actors can gain access to log files, microservices,  internal endpoints, and headers. This may give them access to system and application logs, product usage data, network traffic data, and user credentials, which provide a wealth of information about your company and its internal infrastructure.

‍

‍

For POC purposes, we also reproduced the query mentioned in the exposed Postman workspace. This query will generate a public URL for a given dashboard page entity GUID. The dashboard page can then be accessed in the form of a static snapshot in the resulting public URL.

‍

‍

‍

Upon visiting the URL in the browser, you will get the dashboard details. 

‍

‍

Leaked API Documentation in Postman Workspace 

In this case, a Postman workspace was found publicly exposing API documentation, including details about endpoints, request parameters, authentication methods, and error codes. To make matters worse, a working token was also leaked. 

‍

‍

This kind of exposure can have serious consequences: attackers could use the detailed endpoint information to exploit vulnerabilities or access restricted resources, significantly increasing the attack surface for targeted threats like SQL injection or denial-of-service attacks. Additionally, competitors or malicious actors might gain insights into proprietary business logic, jeopardizing confidentiality and giving them an unfair advantage.

‍

‍

In this particular case, the api was used to send whatsapp messages on behalf of the organization with their whatsapp account. Using the token researchers were able to take complete control over the account and can send any kind of sms/message to the user, this could be easily used to phish users to install a malicious software or get their credentials.

‍

‍

How Sensitive Data Leaks Occur in Postman

Several common scenarios and practices lead to sensitive data leaks within Postman. These often lack from inadequate access controls, accidental sharing, and insecure storage practices. 

‍

A Postman collection is a structured group of API requests, organized with relevant data like parameters, headers, and authentication details, designed to simplify testing and collaboration.

‍

Here are some typical causes of data exposure:

• Inadvertent Sharing of Collections and Environments

One of Postman’s strongest features is its collaboration capability, allowing team members to share collections and environments for efficient development. However, this can also lead to unintended exposure if sensitive data is embedded in shared collections. When environments containing sensitive variables are shared across teams or with external collaborators, unauthorized users may gain access to confidential information.

• Syncing with Publicly Accessible Repositories

In some cases, Postman collections and environment files are synced or exported and stored in public repositories like GitHub. If sensitive data isn’t masked or sanitized before these files are uploaded, it becomes accessible to anyone with access to the repository. This is a common vulnerability, as developers may inadvertently publish tokens or secrets without realizing the impact.

• Misconfigured Access Controls

Postman allows users to set different levels of permissions, but misconfigured access controls can lead to broad access where only restricted access should be allowed. If sensitive environments are shared organization-wide or even made public by mistake, this can result in a substantial data leak.

• Storing Sensitive Data in Plaintext

Postman often saves environment variables and other data in plaintext format, which can be viewed by any user with access to the Postman workspace or environment file. This lack of encryption for locally stored or shared sensitive information makes it susceptible to exposure, especially on shared or compromised devices.

• Use of Long-Lived Tokens Without Rotation

In API testing, it’s common to use tokens to authenticate requests. Many teams opt for long-lived tokens to avoid constant re-authentication. However, if these tokens are not rotated frequently or are hardcoded into Postman, they can become high-value targets. If exposed, these tokens could provide prolonged unauthorized access to systems.

Impact of Sensitive Data Leaks in Postman

Sensitive data exposure within Postman can have significant consequences for both individual developers and entire organizations. A leaked API key or access token, for example, can provide attackers with direct access to critical systems and data, potentially leading to:

• Data Breaches: Attackers can leverage exposed keys to access and exfiltrate sensitive data, leading to financial loss, reputational damage, and regulatory penalties.
• Unauthorized System Access: If attackers gain control of tokens or credentials, they could impersonate legitimate users or applications, granting them unauthorized access to internal systems or services.
• Increased Phishing and Social Engineering Attacks: Attackers can use compromised credentials to launch targeted attacks, such as phishing or social engineering, to further infiltrate an organization.

‍

A Postman workspace is a collaborative environment where users can organize and share API collections, environments, and other resources with team members for streamlined development and testing.

‍

The data highlights a concerning discovery of over 30k Postman Public collections exposing sensitive API keys and credentials across a wide range of platforms and services. Here are some critical insights:

‍

• Leak of Top API Services: Platforms like api.github.com (5,924), slack.com (5,552 leaks), and hooks.slack.com (4,961) dominate the list, showing a high volume of exposed secrets.
• Leak of Popular API Services: High-profile services such as salesforce.com (4,206), login.microsoftonline.com (1,729), and graph.facebook.com (1,174) highlight the widespread nature of this issue, impacting critical cloud, social media, and business ecosystems.
• Leak of Diverse API Services: Exposures range from developer-focused tools like api.twilio.com (283) and api.openai.com (262) to e-commerce and payment systems such as api.stripe.com (554) and api.razorpay.com (704).

‍

‍

This data underscores a significant gap in API security practices and emphasizes the urgent need for stricter controls on how API keys and credentials are managed in collaborative development environments. A pie chart visualizing the proportions could further highlight the concentration of leaks among the top services.

‍

‍

Common Types of Sensitive Data Stored in Postman

Sensitive information is often used within Postman to authenticate and communicate with APIs. This data typically includes:

• API Keys and Secrets: Unique identifiers that grant access to APIs, commonly stored in Postman for ease of use during testing.
• Access and Refresh Tokens: Used for authentication, particularly in OAuth2 flows, these tokens are often long-lived and, if leaked, can be used to impersonate legitimate users.
• Usernames and Passwords: Basic authentication is sometimes used within Postman collections, making credentials vulnerable to exposure.
• Client Secrets and Certificates: Essential for encrypted communications, these are often stored in Postman to facilitate testing but can be highly sensitive if accessed by unauthorized users.
• Environment Variables:
  Configuration settings for production or staging environments, often including internal URLs or sensitive operational data.

Personally Identifiable Information (PII): Customer or employee data that, if mishandled, could lead to privacy violations and compliance issues.

Best Practices to Prevent Data Leaks in Postman

To keep your sensitive data safe in Postman, here are some best practices:

• Use Environment Variables Wisely: Instead of hardcoding sensitive information, use environment variables for tokens and secrets. However, make sure to store them securely and clear them when they’re no longer needed.
• Limit Permissions: Only share collections and environments with people who need them. Review permissions regularly, and avoid organization-wide sharing of sensitive environments.
• Avoid Long-Lived Tokens: Use short-lived tokens when possible, and consider using automated token rotation. This limits the impact if a token does end up exposed.
• Use External Secrets Management: Consider integrating secrets management tools that can securely store and retrieve sensitive information, rather than saving secrets directly in Postman.
• Monitor and Log Access: Postman offers activity logs that track sharing and access. Use these logs to audit who accessed sensitive data and look for any suspicious activity.
• Double-Check Before Sharing: Before sharing any collection or environment, take a moment to review for sensitive information that may have been saved in variables or requests.

Postman’s Response

Commendations to the Postman Security Team for their prompt and effective response in strengthening platform security. Following the disclosure of our findings, they implemented a comprehensive secret-protection policy to mitigate the exposure of sensitive data, such as API keys, in public workspaces. This policy proactively notifies users if secrets are detected, offering resolutions and facilitating transitions to private or team workspaces. These decisive measures underscore Postman’s dedication to user safety and the integrity of their Public API Network. Learn more about these updates here.