Should you store secrets in environment variables?

Should you store secrets in environment variables?

Short answer: avoid it for production secrets. Environment variables are a fine place for non-secret config (feature flags, public URLs, log level). They are a poor vault. Once a process can run code on the box, or once a log line dumps process.env, every value in that environment is available in plaintext. That is CWE-526: Exposure of Sensitive Information Through Environmental Variables, and groups such as TeamTNT have automated it against cloud workloads.

The twelve-factor app told you to put config in the environment so the codebase could be opened without leaking credentials. That part is still right: do not commit the database URL. The part that aged badly is treating the environment as the store. The store should be a secrets manager. The environment, if you use it at all, should hold a reference.

If a secret does leak, the incident looks like secrets exfiltration. If it leaks through a log line, the fix is redacting sensitive data from logs.

Why do env vars help an attacker move laterally?

Think of the environment as a label on every process: DATABASE_URL, STRIPE_SECRET_KEY, AWS_SECRET_ACCESS_KEY. Your application might be locked down. Those strings open the next hop.

You can see the shape locally:

1
env

1
import os
2

3
for key, value in os.environ.items():
4
    print(f"{key}: {value}")

Every language has the same call. Remote code execution, a debug endpoint, a template that prints config, or a malicious dependency that reads os.environ is enough. The attacker stops attacking your app and starts using your database, your object store, and your third-party APIs. The env var was the pivot, not the prize.

How do environment variables leak by accident?

console.log(process.env) during a local debug session is the usual story. The line ships. A request in production hits it. The logging vendor now has every secret that process was started with. Crash dumps, Kubernetes env: in a support bundle, and docker inspect are the same class of mistake.

Redact before the record leaves the process. That means structured logging with an allow-list of fields, not a denylist of key names you remember to hide. See the slog LogValuer pattern in redacting sensitive data from logs.

Why are env vars a bad way to manage secrets?

There is no audit trail for who read DATABASE_URL last Tuesday. There is no version history when someone overwrites it. Rotation means restarting every process that cached the old value, in every environment, without mixing staging and production. Drift is the steady state: your laptop, the preview deploy, and production disagree, and you find out during an incident.

A secrets manager exists to give you those operations: who accessed what, which version is live, and a rotation that does not require a human to edit three dashboards.

How does runtime secrets injection work?

Fetch the value when the process needs it, from a store that authenticates the workload. Three patterns show up in production.

Set the environment variable to an ID, not the secret

This is the portable option when you span more than one cloud. DATABASE_PASSWORD holds arn:aws:secretsmanager:us-east-1:123456789012:secret:payments/db-9xYz (or a GCP Secret Manager resource name). At startup you pattern-match the ID, call the provider, and cache the result in memory for the process lifetime (or until a refresh). If the value does not look like an ID, fall back to the raw string so local development and CI can still use a .env that is never deployed.

Libraries that already abstract this include koanf and Konf in Go, and similar config loaders in other languages. The tool name is koanf (not "konaf"). A worked Go example using koanf plus AWS Secrets Manager:

1
package main
2

3
import (
4
  "context"
5
  "fmt"
6
  "log"
7
  "os"
8
  "strings"
9

10
  "github.com/aws/aws-sdk-go-v2/aws"
11
  "github.com/aws/aws-sdk-go-v2/config"
12
  "github.com/aws/aws-sdk-go-v2/service/secretsmanager"
13
  "github.com/knadh/koanf/providers/env"
14
  "github.com/knadh/koanf/v2"
15
)
16

17
func resolveSecret(ctx context.Context, raw string) (string, error) {
18
  if !strings.HasPrefix(raw, "arn:aws:secretsmanager:") {
19
    return raw, nil // local or CI plaintext fallback
20
  }
21

22
  awsCfg, err := config.LoadDefaultConfig(ctx)
23
  if err != nil {
24
    return "", fmt.Errorf("load aws config: %w", err)
25
  }
26
  client := secretsmanager.NewFromConfig(awsCfg)
27
  out, err := client.GetSecretValue(ctx, &secretsmanager.GetSecretValueInput{
28
    SecretId: aws.String(raw),
29
  })
30
  if err != nil {
31
    return "", fmt.Errorf("get secret: %w", err)
32
  }
33
  if out.SecretString == nil {
34
    return "", fmt.Errorf("secret %s has no string value", raw)
35
  }
36
  return *out.SecretString, nil
37
}
38

39
func main() {
40
  ctx := context.Background()
41
  k := koanf.New(".")
42
  err := k.Load(env.Provider("APP_", ".", func(s string) string {
43
    return strings.ReplaceAll(strings.ToLower(strings.TrimPrefix(s, "APP_")), "_", ".")
44
  }), nil)
45
  if err != nil {
46
    log.Fatal(err)
47
  }
48

49
  password, err := resolveSecret(ctx, k.String("database.password"))
50
  if err != nil {
51
    log.Fatal(err)
52
  }
53

54
  // Use password to open the database. Do not log it.
55
  _ = password
56
  fmt.Println("resolved database password from", os.Getenv("APP_DATABASE_PASSWORD"))
57
}

A developer laptop sets APP_DATABASE_PASSWORD=local-dev-only. Production sets APP_DATABASE_PASSWORD to the ARN. The same binary runs in both places. IAM on the task role, not a copied string, is what authorizes the fetch. The log line prints the ARN or the words "local-dev-only", never the live password.

Call the platform secrets manager directly

If you are committed to one cloud, skip the indirection and use the SDK with the secret name. Grant the task or function an IAM role that can read only that secret. You get type-safe APIs, CloudTrail on GetSecretValue, and no plaintext in DescribeTaskDefinition.

1
func getSecret(ctx context.Context, name string) (string, error) {
2
  awsCfg, err := config.LoadDefaultConfig(ctx, config.WithRegion("us-east-1"))
3
  if err != nil {
4
    return "", err
5
  }
6
  client := secretsmanager.NewFromConfig(awsCfg)
7
  result, err := client.GetSecretValue(ctx, &secretsmanager.GetSecretValueInput{
8
    SecretId: aws.String(name),
9
  })
10
  if err != nil {
11
    return "", fmt.Errorf("error fetching secret: %w", err)
12
  }
13
  return aws.ToString(result.SecretString), nil
14
}

Call this at startup or on a refresh interval. Do not call it on every request unless the SDK's cache is in front.

Use a dedicated secrets product

Doppler, HashiCorp Vault, 1Password, and Infisical sit above the clouds and sync the same name into AWS, GCP, and Vercel. You define the secret once. They handle rotation policy, audit, and per-environment versions. Use one of these when the alternative is three copies of the same value and a spreadsheet of which dashboard is source of truth.

What should you do instead of env-as-vault?

1. Fetch production secrets at runtime from a manager, authenticated as the workload.
2. If you must put something in the environment, put the ID, not the value.
3. Sanitize logs. An env dump is a breach report.
4. Keep local plaintext out of git and out of the production image.

Environment variables are convenient. Convenience is how a single RCE becomes a database dump. Put the secret behind an identity that can be revoked without restarting the universe, and keep the plaintext out of env.