Security

An overview of our security policies and standards

Our infrastructure runs on data centers provided by Amazon Web Services (AWS), which have many security measures in place. We adhere to platform best practices as outlined here.

Postman servers run on stable, regularly patched, versions of Ubuntu with carefully-configured security groups, VPC isolation across environments, 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 code that attempts to break set security policies.

We have also instituted a standardized security stack, that is Node Security (nsp) 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. 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.

  1. Identify, analyze and assess the extent of breach
  2. Attempt at closing the breach. Priority is to take service offline if the breach is active during the process.
  3. Inform the directly affected customer subset if this is a breach caused due to our negligence and post obtaining permission, inform the breach to all indirectly affected customer subset.
  4. In case of a global breach, we perform the above steps and inform all our customers through any of our public communication channels.
  5. In case the breach can recur in the future, we set up security regression checks on network code layers.

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 security@getpostman.com. We will review it and personally respond to you within 24 hours.

If you are a security researcher, please go through the following points for reporting security issues.

  1. Mail to security@getpostman.com and express interest along with a short summary of the nature of issue you want to report.
  2. We will triage and add your email address to our internal security tracker.
  3. Subsequently you can report your security issues directly using the tracker.

Read our security reporting guidelines and policy for more details.