Security Fact Sheet

Security is at the heart of every line of code we write and every new feature we design. Truly secure systems are very hard to build, and what's considered "secure" is a constantly moving target. We adhere to a set of principles that emphasize designing with security in mind from day one. We build features around secure defaults and adhere to the principles of least privilege.

This document provides an overview of Doppler's threat model, including relevant security controls we've put in place. This includes using end-to-end encrypted communication channels, encrypting data at rest, ensuring our internet-exposed infrastructure never persists customer secrets, capturing an immutable audit log, limiting allowed actions via user roles, and providing several strong user authentication options. This document also highlights our general architecture and the flow of data into and out of our servers.

Data Flow Architecture

All traffic to dashboard.doppler.com, api.doppler.com, and related subdomains is routed through Cloudflare. Cloudflare enforces TLS with HSTS and requires a minimum of TLS 1.2. Traffic leaving Cloudflare is proxied over TLS 1.2/1.3 to Google Cloud Platform (GCP). All of Doppler’s servers run within private VPCs in GCP's us-central1 region, with distinct primary and failover compute infrastructure.

When our web servers receive secrets, they are immediately sent to our internal tokenization service. The tokenization service responds with an opaque token that can be safely persisted in the web servers' database. If one of Doppler's web servers/databases were to be breached, an attacker would only gain access to these opaque tokens.

Doppler's tokenization service encrypts all secrets with AES-GCM using a random IV and the workplace's unique 256-bit key. This workplace key is only made available to the tokenization service during the lifetime of the request, and is never persisted outside of application memory. All workplace keys are encrypted using an HSM-backed key accessible via GCP KMS. When Enterprise Key Management (EKM) is enabled, the workplace encryption key is additionally encrypted using your cloud provider's KMS. Doppler's tokenization service strictly limits egress to a list of allowed hostnames.

TLS Encryption

All traffic is encrypted with a minimum supported TLS version of 1.2. Doppler employs HTTP Strict Transport Security (HSTS) with a max-age of 1 year with preloading enabled. Cloudflare is configured with the TLS encryption mode "Full (strict)".

Failover and Fallback

Doppler has two layers of fault tolerance: failover and fallback.

Failover

Failover is built directly into Doppler’s routing layer through Cloudflare Workers. In the event of an outage affecting our primary servers, Cloudflare will begin to direct traffic to our failover servers. The failover servers run hot in distinct availability zones to reduce blast radius while ensuring minimal downtime.

Fallback

Fallback is a feature built into Doppler’s CLI. In the event your machine cannot reach Doppler’s APIs, such as losing internet access, the CLI will automatically read your secrets from a local, encrypted backup. This backup file is updated on each successful secrets fetch. This can also be used to create a local backup during your build, ensuring your secrets are always accessible at runtime.

Command Line Interface (CLI)

Doppler's CLI makes it easy to manage your secrets and make them accessible to your applications. When using the CLI, all sensitive credentials (like your auth token) are saved in your OS's keychain. This prevents these credentials from being stored on disk. Currently, this is supported on macOS, Windows, and Linux. You can find more info on Doppler's CLI here.

Data Durability

Doppler ensures data durability via a high availability Postgres cluster and by taking regular snapshots.

High Availability

All Doppler databases are hosted on GCP's Cloud SQL, which is a database cluster and management system designed to maintain database availability in the face of hardware, software, and even data center failure. When a primary database fails, it is automatically replaced with another replica database called a standby.

Snapshots

Doppler regularly and automatically creates snapshots of its databases through GCP's Automated Backups feature.

Audit Logs

Doppler helps ensure non-repudiation via an immutable audit log. All secret modifications generate an audit log that's attributed to the user that made the change. Secret modifications and other actions can be rolled back from the audit log via users with sufficient permissions.

User Authentication

Doppler supports several strong authentication methods to allow users to avoid having to manage another password. Supported authentication methods include username/password, Google Auth (via OAuth), GitHub, and SAML 2.0. Users utilizing traditional username/password are actively encouraged within Doppler to enable multi-factor authentication (MFA). Supported MFA methods include WebAuthn, OTP, and Authy. Users are also strongly encouraged to generate and store their password in a password manager, such as 1Password, Bitwarden, or Dashlane.

Doppler hashes all user passwords with the bcrypt hashing algorithm. Currently, 14 salt rounds are used when generating hashes. As Doppler increases the number of rounds over time, passwords previously hashed with fewer rounds are rehashed at the next login. This operation can only occur at login as this is the only time Doppler has access to the password. Additionally, during login and password updates, user passwords are securely checked against known data breaches via Have I Been Pwned's k-anonymity model. If a password has previously been exposed in a breach, it may not be used and must be updated.

Employee Data Access

Doppler builds its tools such that employees cannot access sensitive customer data without explicit customer approval. This data includes, but is not limited to, secrets, Doppler issued API keys, and user audit logs. Doppler does not and will never build a "God Mode" for our internal tools. It is your data, not ours.

Doppler also enforces security key-based MFA for all services, where supported, including Google. This policy helps prevent the use of MFA methods that can be phished.

Customer Support

In the rare case a Doppler support agent needs to access your workplace, you will need to manually grant them access by inviting their email in the team page. It is recommended to restrict their access to only the projects and environments that need assistance. Once the support ticket has been closed, you should revoke the support agent's access (should you forget, the support agent can remove themself).

External Penetration Testing

Doppler believes very strongly in external validation of its security controls. If Doppler cannot, for example, convince third-party penetration testers that it is doing its due diligence, how can it expect to convince its customers? After all, security issues don't suddenly stop appearing once a company decides to stop looking. In short: Doppler openly invites outside scrutiny.

Doppler also contracts with various security firms to ensure at least one well-scoped external penetration test is performed annually. Doppler may also contract with various security firms to audit critical new features during their design phase, as appropriate.

Web Application Security

Building a secure web application is a multifaceted problem. As one very small step, Doppler utilizes the latest HTTP security headers. Headers alone cannot protect a web app, but they can be a valuable tool for defense in depth. Doppler employs a strict Content-Security-Policy to help mitigate XSS. Additionally, all cookies are signed, marked httpOnly, and use an explicit sameSite value of at least Lax.

Bug Bounty Program

Doppler is always looking for ways to improve security for our customers. If you would like to report a security vulnerability or other security-related finding, please do so via our Bug Bounty Program.

You may also report findings to us via [email protected]. If doing so, you may choose to encrypt your communication via OpenPGP. You can find our security team's public key here.

Public Security Advisories

Doppler is committed to the practice of transparency regarding customer notification of security vulnerabilities discovered in the product.

We publish a list of all customer-affecting security vulnerabilities here. We will also email customers advisory details in cases where customer data has been affected or customer action is required.

Doppler IP Ranges

Outbound

Doppler currently makes requests from the following IP addresses:

34.72.116.160  
35.225.173.138  
34.41.242.137  
34.121.232.141  
34.30.81.34  
34.72.233.184  
34.136.103.169  
34.27.178.190

The IP list is also available via this JSON endpoint: https://api.doppler.com/_/outbound-ips

These IP addresses may change at any time in Doppler's sole discretion, with or without notice. However, Doppler will undertake reasonable efforts to provide fourteen (14) days advance email notice of any change where possible to customers subscribed to the email notification list.

If you'd like to be added to the notification list, please contact support.

Inbound

Doppler services are fronted by Cloudflare, so requests made to our dashboard or API will be hitting Cloudflare IP addresses. These IP addresses are managed by Cloudflare and as such are subject to change without notice. In the event you need these IPs to open up outbound traffic for API or CLI requests to Doppler, you can obtain Cloudflare's IP ranges here. That said, in scenarios like that, we still recommend using domain filtering instead to have more fine-grained control over what access is being allowed. The following domains are used by the CLI:

Core Functionality (required)

• api.doppler.com

Analytics (optional)

• cli.doppler.com

Updates (optional)

• cli.doppler.com
• objects.githubusercontent.com
• raw.githubusercontent.com

Artificial Intelligence (AI)

Doppler does not utilize AI technologies in our product offerings at this time.