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 infrastructure never persists any customer secrets, capturing an immutable audit log, limiting allowed actions via pre-defined 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 flows between the outside world and Doppler in 3 distinct paths (illustrated below). All of these paths, as well as all communication channels within our infrastructure, strictly enforce SSL/TLS (henceforth referred to as TLS) and required a valid certificate chain.
All traffic to dashboard.doppler.com, api.doppler.com, and related subdomains is routed through Cloudflare's DNS nameservers. Cloudflare enforces TLS with HSTS and requires a minimum of TLS 1.2.
All traffic leaving Cloudflare is proxied over TLS to Google Cloud Platform (GCP). All of Doppler’s servers run in private VPCs on GCP. The primary servers run in the Iowa, USA region with failover servers and databases located in Virginia, USA. In the event of an outage on the primary cluster, Cloudflare will automatically direct traffic to the failover servers. You can learn more about failover in section Failover and Fallback below.
When sensitive data enters GCP, it is immediately sent to our security provider (VGS), who tokenizes it with a secure cryptographic function. This tokenization process is similar to how Stripe handles sensitive card data. Once the data is tokenized, all of Doppler’s servers use only this tokenized data. This helps to ensure that your sensitive data is never stored anywhere on Doppler's infrastructure. Additionally, it also ensures that if Doppler's infrastructure were breached, an attacker would only have access to these tokens. Due to the nature of the cryptographic function used to tokenize the data, it would be computationally infeasible to reverse the token back to its original value.
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 SSL/TLS encryption mode "Full (strict)".
Doppler has two layers of fault tolerance: failover and fallback.
Failover is built directly into Doppler’s DNS 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 on a different managed infrastructure product to reduce blast radius while ensuring minimal downtime.
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.
Doppler ensures data durability via a high availability Postgres cluster and by taking regular snapshots.
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.
Doppler regularly and automatically creates snapshots of its databases through GCP's Automated Backups feature.
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.
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), 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.
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.
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).
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.
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.
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.
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.
Updated 2 months ago