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. We aim to improve our users' security posture by strongly promoting technologies like MFA and password managers. And we do all this while constantly working to make our users more productive.
This document provides a high-level overview of some of the security controls we've put in place. This includes using end-to-end encrypted communication channels, encrypting data at rest, and ensuring our infrastructure never persists any customer secrets. 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 doppler.com and related subdomains is routed through Cloudflare's DNS name servers. 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 and tokenized 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. All Doppler domains employ HTTP Strict Transport Security (HSTS) for 1 year with preloading enabled.
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 and Feature-Policy to help mitigate XSS. Additionally, all cookies are signed, marked httpOnly, and use an explicit sameSite value of at least Lax.
Doppler has 2 layers of fault tolerance built-in: 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 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 passwords. 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. You should always revoke their access after the support ticket has been closed.
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 Vulnerability Disclosure Program (VDP).
Updated 6 days ago