Security Risks of Postman  ## Metadata - Author: [[leeholmes.com]] - Full Title: Security Risks of Postman - Category: #articles - Document Note: --- tags: #SecurityRisks #APIs #SoftwareDevelopment Author: Virtual Assistant Source: Postman Blog Reference: N/A --- # Title: Security Risks of Postman ## 📝 Summary: Postman, a popular tool for testing remote web APIs, poses significant security risks due to its cloud-only approach. Sensitive data, including production secrets, is automatically synced to the cloud, increasing the exposure to potential exploitation. The platform's evolution into a social network for API requests exacerbates these risks, warranting a critical evaluation of its security measures. ## 📖 Main Content: Postman's shift to a cloud-centric model heightens security vulnerabilities, especially concerning the exposure of sensitive credentials stored within the application. Despite claims of encryption and industry standards compliance, the platform's susceptibility to traditional attacks like phishing or credential stuffing remains a concern. The lack of robust security measures and encryption enable attackers to exploit these vulnerabilities, potentially leading to severe consequences. ### 🗒️ Notes - Postman's transition to a cloud-only product raises new security threats due to the syncing of sensitive data, such as production secrets. - Users' self-managed accounts become the access point to valuable information, compromising organizations' security postures. - Attackers target repositories like Postman for authentication material, increasing the likelihood of security breaches and data compromise. - Alternative tools like Insomnia and Bruno offer secure, offline-only data storage options and seamless migration from Postman. - Organizations can mitigate Postman's risks by transitioning users to alternative platforms and enhancing security protocols and data protection mechanisms. ## 📖 References: - Postman Security Blog - Insights from data analysis on Postman users' history and sensitive credential exposure ## 🗣️ Paraphrase: "Rather than enhancing security measures to address escalating risks, Postman's cloud-oriented model inadvertently exposes users to sensitive data compromises, facilitating attacks and unauthorized access." ## 🧪 Hypotheses: - Future research could investigate the effectiveness of encryption protocols in mitigating data breaches on cloud-based platforms. - Studies examining user behaviors and compliance with security measures in API testing tools could provide valuable insights into data security practices. ### 📊 Methodology: - Research could involve surveying developers and security experts to gauge perceptions of postman's security vulnerabilities and explore best practices for secure API testing. - Data analysis of historical breach incidents related to API testing tools could offer a comparative study to assess the risks associated with differing software models. ### ❓ Questions: - How can organizations effectively balance usability and security in API testing tools like Postman? - What measures could postman implement to enhance security features and protect sensitive data from potential breaches? - Are there legislative implications for the data protection standards of cloud-based tools like Postman in regulatory environments? ### 🔮 Future Research: - Areas ripe for future research include quantifying the financial and reputational costs of data breaches related to API testing software. - Exploring emerging technologies like blockchain for enhancing the security features of API testing tools may provide novel insights into data protection issues. ### 💡 Implications: - Advancing research in API testing tool security could inform industry practices, cybersecurity strategies, and regulatory frameworks. - Integrating more robust security protocols in cloud-based platforms could enhance data privacy, customer trust, and resilience against cyber threats. ### ✅ Logical validity: The author effectively delineates the inherent security vulnerabilities in postman's cloud-only approach, providing empirical data and logical arguments to substantiate the concerns raised. ## 🎯 Conclusion: Postman's security risks necessitate a critical evaluation of its data protection protocols and migration to more secure alternatives. Organizations must prioritize data security and mitigate vulnerabilities to safeguard against potential breaches and mitigate financial and reputational risks. - Document Tags: [[cybersecurity]] [[security]] - Summary: Postman, a popular tool for testing APIs, has security risks when using its cloud features. Postman's cloud sync can expose sensitive data, and its lack of robust security measures has led to concerns among users. Consider using alternative tools like Insomnia or Bruno to mitigate these risks. - URL: https://www.leeholmes.com/security-risks-of-postman/ Postman is an extremely popular application for developers testing remote web APIs. It lets you craft HTTP requests, interact with their responses, and go through the history of what you’ve sent and received. Many of these HTTP requests are authenticated, meaning that the application deals with API keys, login tokens, credentials, etc. In May, Postman [pivoted to be a cloud-only product](https://blog.postman.com/announcing-new-lightweight-postman-api-client/) for many of its features. ### Postman’s Security Risk When you log in to Postman, it automatically syncs all data to their cloud service – including sensitive data contained in these requests. For example, here is the cloud view of Postman when all I’ve ever used was the on-premises application.  ### Changes to the Postman Threat Model Cloud connectivity is of course not a security threat, but it does mandate that the product or company account for the new risks in the threat model. This change introduces several major changes to Postman’s security risks: * A user’s self-managed Postman account credentials now provide access to any production secrets they may been using. If your organization enforces identity separation when managing production resources, these self-managed Postman accounts now break that. * Traditional attacks (phishing, credential stuffing, etc.) against Postman accounts will now likely result in exposure of production secrets. * As [Okta’s recent breach demonstrates](https://krebsonsecurity.com/2023/10/hackers-stole-access-tokens-from-oktas-support-unit/), attackers do go after companies that store authentication material to abuse them and replay them against their original targets. In addition to these kind of issues, Postman is also heading down a path of being a social network for API requests. If you thought people accidentally checking creds into GitHub was a problem, wait until attackers discover the treasure trove that is Postman.  Postman has received an enormous amout of feedback about the security risks of this approach. For over a year, they defended this approach and opted to not make any changes to account for them. Their [security page](https://www.postman.com/trust/security/) mentions only the most basic, check-box style of security: > We use cryptographic methods and industry standards to protect customer data in transit between Postman clients, the cloud, and at rest. For example, all communications and data in transit over the internet require the latest version of Transport Layer Security, a cryptographic protocol that provides end-to-end encryption. By default, encryption is also enabled on all our services that contain data at rest. > > Also, your sensitive data at rest is encrypted on the server side before storage using AES-256-GCM. The Advanced Encryption Standard with Galois Counter Mode (AES-GCM) provides authenticated encryption, which ensures data confidentiality and integrity. > > In recent months, Postman has added features (variables with only a [“Current " value](https://learning.postman.com/docs/sending-requests/variables/variables/#initial-and-current-values) and as of May 2024 - [Postman Vault](https://learning.postman.com/docs/sending-requests/postman-vault/manage-vault-secrets/)) that – if you use correctly and never make a mistake – might be possible to use securely. As the “Measured Risk” section below illustrates, though, it is nearly impossible to walk this line correctly. This makes Postman not worth the risk given its viable alternatives. ### Measured Risk In a large data set that we sampled: * 56% of Postman users discovered sensitive credentials when they reviewed their history. * 30% of those were *still valid*, which we then had to rotate. * The other 70% were valid *at some point*, so would have represented spillage if an attacker had active access to either the user’s account or Postman infrastructure. * Nobody found any blocking issues preventing them from moving to an alternative client. ### Alternatives to Postman There are several popular alternatives to Postman: * [Insomia](https://insomnia.rest). While Insomnia does require an account, they do support local-only storage of data. For cloud-hosted content, they have explicitly implemented features (such as [end-to-end encryption](https://docs.insomnia.rest/insomnia/security-features)) to ensure that their servers never see any sensitive information. If even this amount of connectivity makes you nervous, there is a fork of Insomnia that removes these features: [Insomnium](https://github.com/ArchGPT/insomnium). * [Bruno](https://www.usebruno.com/). Also very popular, and offline only. * [Visual Studio](https://learn.microsoft.com/en-us/aspnet/core/test/http-files) (including rich support for secrets), PowerShell’s [Invoke-RestMethod](http://powershellcookbook.com/recipe/Vlhv/interact-with-rest-based-web-apis), [Curl](https://curl.se/docs/httpscripting.html), etc. Insomnia and Bruno support import from Postman. ### Eliminating Postman in your Company Here is a rough playbook for how you can eliminate Postman in your company. Your mileage may vary, of course. 1. Determine your population of Postman users. We were able to get this list through endpoint URL usage data of users connecting to <https://identity.getpostman.com>. 2. Instruct these users to: Log in (or open) Postman, go the History tab. Review any entries with an “Authorization” header, or other sensitive headers. Rotate any credentials associated with any of these that have been saved. Review any entries that use URL-based authorization (such as SAS keys for Azure Storage, pre-signed AWS URLs, web hooks, etc.). Rotate any credentials associated with any of those that have been saved. After remediation, clear your Postman history and close your account. Explore Insomnia, Insomnia, or Bruno as alternative clients. 3. Record their completion in a survey form. We used an Office Form with the following questions: 1. I have reviewed my Postman history. Regarding sensitive material: 1. The sensitive credentials / secrets have already expired 2. I have rotated the sensitive credentials / secrets 3. I am in the process of rotating the sensitive credentials / secrets 4. There is sensitive material but I am unsure of the right next steps. I have reached out to [contact] 5. There was no sensitive material 2. I have discontinued use of Postman Cloud 1. Yes, and have found an alternative 2. Yes, will search for an alternative as needed 3. No, I am blocked and have reached out to [contact] 4. Use whatever process you have in your company or organization (including escalations, CCing managers, directors, etc.) to burn down the list of employees that have used Postman but not responded to the survey. Of course, actively support those reaching out. ### Automating History Analysis Ideally, you could automate step 3.1 above by running a secrets analysis tool like [CredScan](https://secdevtools.azurewebsites.net/helpcredscan.html) on a directory of content. Unfortunately, we were not able to find a reasonable path to automate history analysis. While Postman does support a feature to export your data, this export is only of collections and similar configurations. It would not export history. Even their GDPR export does not include history. Additionally, the local and web clients use an undocumented and complicated websocket protocol to interact with the Postman service itself, which would have turned into a pretty extensive reverse engineering and software engineering exercise., Security Risks of Postman, leeholmes.com, 01hz2txvxxr01y8erssczd4vp4.