Best practices for securing secrets in staging environments

A tweet with over 1.7 million views recently made the rounds:

Security breaches - an API key pushed to GitHub are all too common

A quick search reveals thousands of public repositories exposing sensitive credentials, often committed by accident from staging or development setups.

A GitHub search finds exposed OpenAI API keys.

Staging environments are meant to mirror production. However, they rarely receive the same level of attention when it comes to secrets management. Developers reuse tokens across environments, leave .env files in version control, or disable access controls “just for testing.”

These shortcuts pile up, exposing real attack surfaces over time. A single leaked secret, particularly one with production-level access, can lead to data loss, service disruption, or even worse consequences.

In this guide, we’ll walk through the most common security gaps in staging and preview environments. You’ll learn how to scope secrets properly, avoid duplication and drift, and inject secrets securely through CI/CD pipelines. We’ll also show how tools like Doppler help teams enforce these practices automatically across every environment.

Why staging environments can become security blind spots

Dev and Production environments are vetted for security. But is staging?

Staging environments are always launched with the best of intentions. In staging, teams can find those bugs that cannot be tested in an isolated dev environment. To mimic production, staging begins to be exposed to the outside world. This means exposure to external parties who might attempt to gain access.

Unfortunately, staging environments often do not have the same monitoring, access controls, or firewall protections afforded to production environments. Over time, staging begins to drift from the original production configurations: hardware changes in prod are not replicated in staging, or staging configs are modified in testing and not reverted back to production settings. A changed firewall rule in staging might accidentally get leaked to production, or a production credential might be inadvertently left in staging after a test. This drift leads to deployment issues and can provide an attack surface for hackers.

In 2024, a hacker used default login credentials on a staging server to gain admin access. Even worse, they were able to leverage the admin JSON Web Token (JWT) created in staging to gain full admin access control in production.

Accidental exposure of credentials is so common that GitHub reported over 39 million secrets and API keys exposed on their platform in 2024 alone. Clearly, locking down and keeping staging environments completely secure and isolated from production environments is a critical component of operational security for any organization.

Common pitfalls when managing secrets in non-prod environments

Managing secrets across numerous environments is a huge challenge. Here are the most common issues that are seen in staging environments:

Credentials with elevated privileges

Using tokens that adhere to the least privilege principle can go a long way in limiting access during a breach.

Hard-coded credentials

Hard-coded secrets are less likely to be changed or rotated, and once exposed, are difficult to change.

Staging drift

Staging and production should be similar to one another, so that code that runs correctly in staging will also run correctly in production. Drift occurs as the staging environment and production environments slowly change and diverge from one another.

Configuration duplication

Perhaps the code in staging needs to be updated to match prod, so the team 'temporarily' connects staging to the production database using production credentials. By duplicating credentials across environments, attackers exploiting an exposed development credential may find that the compromised secret gives access to staging. If there is excessive duplication, they can even jump laterally to production environments.

Monitoring

Monitoring can be expensive. Since staging is typically used only by development or QA teams before deployment, the same level of security monitoring is not deployed in staging as in production. Due to this lack of monitoring, any breach that occurs in staging may not be noticed.

Logs

When diagnosing bugs in staging, developers may set logging to verbose. Hackers who gain access to staging will have access to any logs that accidentally leak customer data or other credentials.

Secrets rotation policies

Secrets rotation may be enforced in prod, but what are the policies about secrets rotation in staging? The longer secrets remain unchanged, the more likely they will be compromised.

Insecure secrets storage

Teams may store .env files in shared files for staging, as the environment has less security oversight.

Secure staging environments

If your staging environment is not secure, you can be sure that attackers will be looking for security vulnerabilities. Using basic security on your staging servers can go a long way. Make sure that TLS certificates are deployed adequately for staging, that server encryption is on, and that firewall rules are correctly set.

Now that we know some common pitfalls that developer teams encounter in staging, how can we address them?

Principles for secure secrets management across environments

Many of the security issues listed above occur when teams store secrets with inadequate security controls or fail to implement updates. A secrets management service like Doppler is a better solution for handling secrets.

Credentials are properly scoped

All tokens should adhere to principle of least privilege, limiting access to only the services and systems required.

Store all secrets securely

If not using a secrets manager, make sure no secrets are hardcoded. Use best practices for storing .env files and any file that might hold credentials or access codes. Inject secrets at build time with CI/CD whenever possible.

Rotate secrets regularly

You should be rotating secrets regularly. The longer secrets remain unchanged, the more likely they are to be compromised.

Staging changes

Monitor all changes to staging. When a change is made in testing, create an issue to have the change reverted so that it is not forgotten. If credentials from dev or prod are temporarily added to staging, double-check that they are removed once the release is made.

Monitoring

Tracking and alerting on credential usage and changes can help teams identify malicious usage, making it easier to identify breaches.

Logs

Be careful with verbose logging that may expose PII, credentials, or other sensitive information.

Security first

Staging requires the same basic security that is on production. Make sure that TLS certificates are properly deployed, that server encryption is on, and that firewall rules are correctly set.

The following security best practices checklist holds for all environments:

• Isolate credentials between environments.
• Automatically rotate secrets at deployment.
• No hard-coded secrets.
• Securely store .env files.
• Automate secrets rotation.
• Revert changes to staging and keep all environments in proper sync.
• Prevent unauthorized access to secrets.
• Scope secrets with least privilege access.
• Monitor of secret usage.

Now that the secrets are securely stored and isolated from other environments, how do secrets management tools inject the secrets into the staging environment?

Strategies for injecting secrets into staging environments

Secrets management solutions like Doppler integrate easily with common CI/CD tools like Jenkins, CircleCI, and GitHub Actions, securely adding secrets to all environments (including staging) on each deployment. This process also ensures that secrets do not become duplicated across environments. Doppler's logging function also measures how often secrets are being used, identifying patterns of misuse.

How to prevent drift and duplication between staging and production environments

As identical environments change over time, settings that should be the same sometimes drift, meaning that the environments are no longer identical. Infrastructure as Code (IaC) tools like Terraform or Pulumi deploy versioned environments that always launch with the same hardware. Doppler, in conjunction with IaC tools, can set the secrets in each instance as they launch (using different credentials in each environment).

Changing a secret in one environment with the option to update other environments with the same secret.

IaC tools (like Terraform's plan tool) are used to measure drift between deployments. Creating a regular automation (perhaps with a GitHub Action) to regularly compare the drift between prod and staging helpful warning that deployments are diverging.

Duplication occurs when secrets and configurations that are supposed to be separated begin to overlap. Secrets management services handle secrets usage across environments, isolating secret usage across each environment. By isolating secrets across deployments, lateral movement to other environments after an intrusion is less likely to occur.

Protecting staging environments takes effort

Maintaining a strong security posture requires constant vigilance at every stage of development. In practice, staging environments are more likely to be ignored from a security perspective, and this lax handling can lead to serious issues. In this post, we walked through general security principles that hold staging environments, but many are best practices for development teams in any environment.

Using strong secrets management across all environments helps organizations maintain a strong security posture, no matter where the code lies. CI/CD automation of secrets injection means that on every deployment, every environment’s secrets (including staging) are updated and kept secure.

Scaling an application to handle growth while supporting many different environments is a huge challenge, even without worrying about properly securing secrets. By avoiding the common security pitfalls and following the best practices checklist, teams can be sure that their staging environment is secure and no longer a vector for intrusions.

If your organization struggles to scale secrets management across many different environments, consider a solution like Doppler.