An overview of our security policies and standards
With nearly 5 million users worldwide using Postman products and accessing Postman services, individuals, small, medium and large organizations count on Postman to meet their data protection and data security needs. We take security very seriously and have developed a comprehensive set of practices and policies to help ensure your data is secure.
Postman servers run on stable, regularly patched, versions of Ubuntu with carefully-configured security groups, isolated VPC environments with well defined network segmentation, role-based Access Control and AWS' advanced firewall protection. We have also instituted separate protection at the Application and Network layers.
We serve our apps and website exclusively over HTTPS and Secure Websockets. All network interactions use TLS with 2048-bit digital signatures and 128-bit AES encryption. We also use HTTP Strict Transport Security to ensure the apps never interacts with the servers over insecure HTTP.
Identity Verification and Protection is done using JSON Web Tokens (JWT cookies), which are 256-bit AES encrypted. These tokens allow Single sign-on into all Postman services through private cloud communication.
Our applications run on the latest stable version of Node.js and are process isolated using Docker to reduce the attack surface. Our security team is involved in setting architectural guidelines, code review, and deployment of every micro-service that can interface with customer data.
Our developers are trained with specific attention towards security. Automated and human code review processes look for any piece of code that attempts to violate security policies. We have also instituted a standardized security stack, that is Node Security compliant and we conduct regular internal audits for code and infrastructure compliance.
All operator access is controlled through a carefully managed and audited security policy that includes Access Control, password policy, BYOD, and Network Access.
All internal services require SSO, with 2FA RSA Authentication. All SSH based access has a mandatory key-file driven policy, where the key-files are stored securely and rotated and all access is logged.
Customer data access is employee role based, enforced using security keys. Only the core team, which is limited to the founders and VP of Engineering, has access to this data. Any data required for customer support (or otherwise) is procured via the core team. The team ensures that the requirement hypothesis is validated and data is obfuscated and sanitized before communicating back to Support or Engineering.
All customer data is stored in MySQL databases on Amazon RDS, which are regularly patched for security. Data is stored with at least dual redundancy, with 15 day backups and is accessible only within the private cloud. We have also instituted per-service access protection and isolation of data.
Customer data, depending upon its sensitivity classification, is also AES-256-GCM encrypted at the application layer before storage. Postman Environment and Global variables are covered in this classification and we strongly encourage their use for storing authentication keys and passwords. We have also added the notion of Sessions in the 6.2 release of Postman. For data which you do not want synced to Postman servers, we recommend using Session variables, which by default do not automatically sync.
Customer data, depending upon its sensitivity classification, is also AES-256-GCM encrypted at the application layer before storage. Sensitive data includes Environment and Global variables, usage of which is highly encouraged for storing authentication keys and password.
We maintain intelligent, web application firewalls on our Load Balancers, which along with the Elastic Scaling capacity of our compute instances are designed to mitigate attacks at the Application layer.
We log activity across our platform, from individual API requests to infrastructure configuration changes. Logs are aggregated for monitoring, analysis, and anomaly detection and archived in vaulted storage. We implement measures to detect and prevent log tampering or interruptions. In order to determine security breaches, we monitor access patterns and network data flow patterns using automated systems that alert us in case of any anomaly. We also keep track of public channels (and private contacts, wherever applicable) of all our open source and third-party technology stack for any security related notice. In case of a customer reported breach, the CTO, CEO and VP, Engineering are notified automatically and the report responded to within a few hours.
Our servers are protected against CSRF (Cross Site Request Forgery) and CSWSH (Socket Hijacking) attacks.
We process all payments using Stripe, which has been certified as a PCI Level 1 Service Provider.
If you’ve found a vulnerability in our service or website, or want additional information regarding how we manage security, please send an email to email@example.com. We will review it and respond to you within 24 hours.
If you are a security researcher, please go through the following points for reporting security issues.
Read our security reporting guidelines and policy for more details.