Secrets Management

20 min read

API keys, database passwords, signing keys, and OAuth client secrets are the crown jewels of any service. In Node you have probably reached for process.env and a .env file and called it done. Rust gives you the same environment-variable workflow plus two type-level tools that JavaScript simply cannot offer: wrapper types that refuse to print themselves in logs, and types that scrub their bytes from memory when dropped. This page shows how to load, hold, and dispose of secrets safely.

Quick Overview

A secret is any value whose disclosure is a security incident: a database password, a third-party API key, a JWT signing key, a TLS private key. Managing them well means three things: getting them in from a trusted source (environment variables or a secret store, never hard-coded), holding them so they cannot accidentally end up in a log line or a panic message, and getting rid of them by clearing their bytes from memory once you are done.

For a TypeScript/JavaScript developer the loading half feels identical — you still read process.env / std::env::var. The new ideas are the secrecy crate, whose SecretString/SecretBox wrappers redact themselves from Debug/Display output, and the zeroize crate, which overwrites a secret’s memory on drop. Neither has a real JavaScript equivalent, because a garbage-collected runtime gives you no control over when (or whether) a string’s bytes are wiped.

Note: This page is about handling secrets your application already trusts. For the cryptography you perform with those secrets see cryptography.md and password-hashing.md; for generating new secret material see secure-randomness.md; for keeping the dependencies that touch your secrets free of known vulnerabilities see security-audit.md.

TypeScript/JavaScript Example

A typical Node service loads configuration from the environment, usually with dotenv in development:

1
// npm install dotenv
2
import "dotenv/config"; // loads .env into process.env (dev only)
3

4
interface Config {
5
  serviceName: string;
6
  bindAddr: string;
7
  databasePassword: string;
8
  jwtSigningKey: string;
9
}
10

11
function loadConfig(): Config {
12
  const required = (name: string): string => {
13
    const value = process.env[name];
14
    if (!value) throw new Error(`missing required env var: ${name}`);
15
    return value;
16
  };
17

18
  return {
19
    serviceName: required("SERVICE_NAME"),
20
    bindAddr: process.env.BIND_ADDR ?? "0.0.0.0:8080",
21
    databasePassword: required("DATABASE_PASSWORD"),
22
    jwtSigningKey: required("JWT_SIGNING_KEY"),
23
  };
24
}
25

26
const config = loadConfig();
27

28
// The classic foot-gun: logging the whole config object.
29
console.log("service starting", config);
30
// service starting {
31
//   serviceName: 'billing-api',
32
//   bindAddr: '0.0.0.0:8080',
33
//   databasePassword: 'vault:db/prod#aB9',   <-- LEAKED into the log!
34
//   jwtSigningKey: 'vault:jwt/prod#Zx1'       <-- LEAKED!
35
// }

Key points:

process.env values are always string | undefined, so every read needs a presence check.
databasePassword is just a string. Nothing stops it from being printed, JSON-serialized into an error response, or shipped to your logging service.
A plain console.log(config) in production is the single most common way real secrets end up in log aggregators.
The bytes of that string live in the V8 heap until the garbage collector decides to reclaim them. You cannot force a wipe.

Warning: The same risk exists with structured loggers (pino, winston) and with JSON.stringify(config) in an error handler. Mitigation in JavaScript is purely convention — a redaction allowlist you must remember to maintain. There is no type that enforces it.

Rust Equivalent

The same loader, but SecretString makes the leak structurally impossible. Add the dependencies first:

1
cargo add secrecy
2
cargo add tracing tracing-subscriber

This pulls in secrecy = "0.10". SecretString is a wrapper whose Debug impl prints [REDACTED] instead of the value, and which exposes the plaintext only through an explicit .expose_secret() call.

1
use secrecy::{ExposeSecret, SecretString};
2
use std::env;
3
use std::fmt;
4

5
struct Config {
6
    service_name: String,
7
    bind_addr: String,
8
    database_password: SecretString,
9
    jwt_signing_key: SecretString,
10
}
11

12
// A redacting Debug so logging the WHOLE config can never leak a secret.
13
impl fmt::Debug for Config {
14
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
15
        f.debug_struct("Config")
16
            .field("service_name", &self.service_name)
17
            .field("bind_addr", &self.bind_addr)
18
            // SecretString already redacts itself; being explicit documents intent.
19
            .field("database_password", &"[REDACTED]")
20
            .field("jwt_signing_key", &"[REDACTED]")
21
            .finish()
22
    }
23
}
24

25
impl Config {
26
    fn from_env() -> Result<Self, String> {
27
        let get = |k: &str| env::var(k).map_err(|_| format!("missing env var: {k}"));
28
        Ok(Config {
29
            service_name: get("SERVICE_NAME")?,
30
            bind_addr: env::var("BIND_ADDR").unwrap_or_else(|_| "0.0.0.0:8080".into()),
31
            database_password: SecretString::from(get("DATABASE_PASSWORD")?),
32
            jwt_signing_key: SecretString::from(get("JWT_SIGNING_KEY")?),
33
        })
34
    }
35

36
    fn database_url(&self) -> String {
37
        // Expose the secret only at the exact site that needs the plaintext.
38
        format!("postgres://app:{}@db/prod", self.database_password.expose_secret())
39
    }
40
}
41

42
fn main() {
43
    tracing_subscriber::fmt().without_time().with_target(false).init();
44

45
    // In production the deployment platform sets these; we set them here to run.
46
    unsafe {
47
        env::set_var("SERVICE_NAME", "billing-api");
48
        env::set_var("DATABASE_PASSWORD", "vault:db/prod#aB9");
49
        env::set_var("JWT_SIGNING_KEY", "vault:jwt/prod#Zx1");
50
    }
51

52
    let config = Config::from_env().expect("config error");
53

54
    // Logging the whole config is now SAFE — the secrets are redacted.
55
    tracing::info!(?config, "service starting");
56

57
    let url = config.database_url();
58
    tracing::info!(url_len = url.len(), "built database connection string");
59
}

Real output (ANSI colour codes stripped for the page):

1
 INFO service starting config=Config { service_name: "billing-api", bind_addr: "0.0.0.0:8080", database_password: "[REDACTED]", jwt_signing_key: "[REDACTED]" }
2
 INFO built database connection string url_len=40

Key points:

SecretString comes from secrecy; SecretString::from(String) moves the plaintext inside the wrapper.
Its Debug output is [REDACTED], so the tracing::info!(?config, ...) line that would have leaked the password in Node prints a safe placeholder instead.
To read the plaintext you must call .expose_secret() from the ExposeSecret trait — an explicit, greppable, code-review-visible action.
The whole-struct Debug impl is belt-and-braces: even non-secret-typed fields added later are not accidentally dumped, and the [REDACTED] markers make intent obvious to reviewers.

Detailed Explanation

Why a wrapper type instead of a `string`

In JavaScript, “don’t log the secret” is a rule you enforce by remembering — and you remember in dozens of places: the startup log, the request logger, the error handler that serializes context, the debugger watch you forgot to remove. SecretString flips this from opt-out to opt-in. The default behaviour of the type is not to reveal itself; revealing requires the conscious act of calling .expose_secret(). You can grep your codebase for expose_secret and audit every single place a secret becomes plaintext. There is no equivalent grep for “every place a plain string might get logged.”

What `SecretString` actually is

In secrecy 0.10, SecretString is an alias for SecretBox<str>, and SecretBox<T> is the general wrapper for any secret value. The wrapper provides:

A redacting Debug (no Display at all — see the pitfall below).
.expose_secret() (from the ExposeSecret trait) to borrow the inner value.
Zeroization of the inner bytes when the SecretBox is dropped, because SecretBox requires its contents to implement Zeroize (covered below). A SecretString wipes the string’s heap buffer on drop; you do not manage that yourself.

1
use secrecy::{ExposeSecret, SecretBox, SecretString};
2

3
fn main() {
4
    // A string secret.
5
    let token = SecretString::from("super-secret-token".to_string());
6
    println!("debug:   {token:?}");          // redacted
7
    println!("exposed: {}", token.expose_secret());
8

9
    // SecretBox<T> for any zeroizable type — e.g. a 32-byte binary key.
10
    let key: SecretBox<[u8; 32]> = SecretBox::new(Box::new([7u8; 32]));
11
    println!("key dbg: {key:?}");             // redacted
12
    println!("first byte: {}", key.expose_secret()[0]);
13
}

Real output:

1
debug:   SecretBox<str>([REDACTED])
2
exposed: super-secret-token
3
key dbg: SecretBox<[u8; 32]>([REDACTED])
4
first byte: 7

The Debug shows the type (so logs are still useful for “a database password is present”) but never the value.

Getting secrets in: environment variables

The most portable source is the process environment, exactly as in Node. The only Rust-specific wrinkle is that std::env::var returns Result<String, VarError>, so you handle the missing case explicitly:

1
use secrecy::SecretString;
2
use std::env;
3

4
/// Read a required secret from the environment into a SecretString.
5
fn require_secret(name: &str) -> SecretString {
6
    let value = env::var(name)
7
        .unwrap_or_else(|_| panic!("missing required env var: {name}"));
8
    SecretString::from(value)
9
}
10

11
fn main() {
12
    unsafe { env::set_var("DATABASE_PASSWORD", "p@ss-from-vault"); }
13

14
    let db_password = require_secret("DATABASE_PASSWORD");
15
    println!("db_password = {db_password:?}"); // redacted
16
}

Real output:

1
db_password = SecretBox<str>([REDACTED])

Note: env::set_var is unsafe in the current edition because mutating the environment is not thread-safe. You only need it in tests/examples; real deployments set env vars outside the process (systemd unit, Kubernetes Secret, container --env, your platform’s secret manager) so your code only ever reads them.

Loading a `.env` file in development

In Node dotenv reads a .env file into process.env. The Rust counterpart is dotenvy (the maintained fork of the original dotenv crate):

1
cargo add dotenvy

1
use secrecy::{ExposeSecret, SecretString};
2

3
fn main() {
4
    // Loads key=value pairs from .env into the process environment.
5
    // Use in DEVELOPMENT ONLY; never commit the .env file.
6
    dotenvy::dotenv().ok();
7

8
    let key = SecretString::from(
9
        std::env::var("STRIPE_SECRET_KEY").expect("STRIPE_SECRET_KEY not set"),
10
    );
11
    println!("loaded secret: {key:?}");
12
    println!("exposed len:   {}", key.expose_secret().len());
13
}

With a .env of STRIPE_SECRET_KEY=sk_test_loaded_from_dotenv the real output is:

1
loaded secret: SecretBox<str>([REDACTED])
2
exposed len:   26

Warning: Add .env to your .gitignore before you ever write a real secret into it. A committed .env is one of the most common ways secrets reach a public repository. (See the project .gitignore conventions and section 24’s tooling notes.) dotenvy::dotenv() should be a dev convenience only — in production, real secret managers inject values directly.

Secret stores and managers

Environment variables are fine for many services, but they have downsides: they are visible to every child process, may appear in /proc, and offer no rotation or audit trail. Mature deployments use a secret manager — HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, Azure Key Vault, or Kubernetes Secrets — and your code fetches at startup (or on a refresh interval). Whatever the source, the pattern is the same: fetch the plaintext, immediately wrap it in SecretString/SecretBox, and from then on the rest of your program handles only the wrapper. Vendor SDK crates (for example aws-sdk-secretsmanager) return the value as a String; your job is to wrap it the moment it crosses into your code.

Getting secrets out of memory: `zeroize`

When a String is dropped its heap allocation is freed, but the bytes are not overwritten — they linger until something else reuses that memory. A core dump, a swapped-out page, or a memory-scraping exploit can recover them. The zeroize crate overwrites secret bytes with zeros, and crucially does so in a way the optimizer is not allowed to elide:

1
cargo add zeroize --features derive

1
use zeroize::{Zeroize, ZeroizeOnDrop};
2

3
#[derive(Zeroize, ZeroizeOnDrop)]
4
struct Credentials {
5
    username: String,
6
    password: String,
7
}
8

9
fn main() {
10
    // Manual zeroize of a buffer you are done with.
11
    let mut secret = String::from("api-token-abc123");
12
    println!("before: {secret:?}");
13
    secret.zeroize();
14
    println!("after:  {secret:?} (len = {})", secret.len());
15

16
    // ZeroizeOnDrop wipes every field automatically when the value drops.
17
    {
18
        let creds = Credentials {
19
            username: "alice".into(),
20
            password: "hunter2".into(),
21
        };
22
        println!("using creds for {}", creds.username);
23
    } // <- password bytes overwritten with zeros HERE
24
    println!("creds dropped and wiped");
25
}

Real output:

1
before: "api-token-abc123"
2
after:  "" (len = 0)
3
using creds for alice
4
creds dropped and wiped

#[derive(Zeroize)] gives you a .zeroize() method that clears every field; #[derive(ZeroizeOnDrop)] runs it automatically in the destructor. secrecy’s SecretBox uses exactly this machinery internally, which is why a SecretString already wipes itself — you typically reach for raw zeroize only for buffers you manage yourself (a decrypted plaintext, a key derivation scratch buffer).

Note: Zeroization is a defence in depth, not a guarantee. The OS may have already copied the page to swap, and a value moved on the stack can leave copies behind. It meaningfully shrinks the window in which a secret sits in recoverable memory; it does not make a secret impossible to recover.

Key Differences

Concern	TypeScript / JavaScript	Rust
Reading env vars	`process.env.X` → `string \| undefined`	`std::env::var("X")` → `Result<String, VarError>`
`.env` files	`dotenv`	`dotenvy` (dev only)
Preventing accidental logging	Convention + logger redaction allowlists	`SecretString`/`SecretBox` redact in `Debug`, no `Display`
Revealing the plaintext	Implicit — it is just a `string`	Explicit `.expose_secret()`, greppable
Wiping memory	Not possible (GC owns the heap)	`zeroize` overwrites bytes deterministically
Wiping on scope exit	Not possible	`#[derive(ZeroizeOnDrop)]` / `Drop`
Serialization safety	`JSON.stringify` leaks by default	`SecretString` opts out of `serde::Serialize` unless you opt in

The deep difference is enforcement vs. discipline. JavaScript can only ask you to remember not to log a secret. Rust’s type system lets a secret refuse to be logged: the compiler will not let you format a SecretString with {}, and its Debug is redacted. Combined with deterministic destruction (Drop/zeroize), you get controls a garbage-collected runtime cannot provide.

Common Pitfalls

Trying to print a secret directly

The compiler stops you from interpolating a SecretString, because it deliberately does not implement Display:

1
use secrecy::SecretString;
2

3
fn main() {
4
    let token = SecretString::from("super-secret".to_string());
5
    println!("token = {token}"); // does not compile (error[E0277]: SecretBox<str> doesn't implement Display)
6
}

The real compiler error:

1
error[E0277]: `SecretBox<str>` doesn't implement `std::fmt::Display`
2
 --> src/main.rs:6:24
3
  |
4
6 |     println!("token = {token}");
5
  |                       -^^^^^-
6
  |                       ||
7
  |                       |`SecretBox<str>` cannot be formatted with the default formatter
8
  |                       required by this formatting parameter
9
  |
10
  = help: the trait `std::fmt::Display` is not implemented for `SecretBox<str>`

This is the feature working as designed: the only way to get the plaintext into a string is the explicit .expose_secret(). Treat this error as a prompt to ask “do I really need the plaintext here, or am I about to log a secret?”

Exposing too early and too widely

.expose_secret() returns a borrow of the plaintext. If you call it at the top of a function and pass the resulting &str around, you have effectively widened the secret back into an ordinary string for that whole scope. Call it at the narrowest possible site — directly inside the format! or the SDK call that needs it — so the plaintext’s lifetime is as short as possible:

1
use secrecy::{ExposeSecret, SecretString};
2

3
fn build_auth_header(api_key: &SecretString) -> String {
4
    // Good: expose only inside the one expression that needs it.
5
    format!("Bearer {}", api_key.expose_secret())
6
}
7

8
fn main() {
9
    let key = SecretString::from("sk-live-9f8b7a6c".to_string());
10
    let header = build_auth_header(&key);
11
    println!("header len = {}", header.len());
12
}

Real output:

1
header len = 23

Forgetting that derived `Serialize` leaks

If you #[derive(Serialize)] on a config struct and the field is a plain String, serde_json::to_string(&config) will happily emit the secret — the same trap as JSON.stringify. SecretString does not implement Serialize by default (you must enable the serde feature and opt in explicitly), so a derived Serialize on a struct containing a SecretString fails to compile rather than silently leaking. Keep secrets in SecretString, or give the struct a hand-written Serialize/Debug that omits them.

Putting secrets on the command line

Passing a secret as a CLI argument (--api-key sk-live-...) exposes it in ps output and shell history to every user on the box — the same hazard as in any language. Read secrets from the environment or a file, not from argv. See 18-cli-tools for argument parsing patterns and how to accept secrets safely (e.g. from stdin or an env var).

Assuming zeroize guarantees erasure

zeroize cannot un-leak a value the OS already copied to swap, nor reach copies left by earlier moves. It is a strong mitigation, not a proof of erasure. Do not let it lull you into being careless about where a secret travels.

Best Practices

Never hard-code secrets. No literals in source, no committed .env. Inject via the environment or a secret manager at deploy time. Gitignore .env before the first write.
Wrap on arrival. The instant a secret enters your process (env read, Vault fetch, file read), wrap it in SecretString/SecretBox. The rest of the program should only ever see the wrapper.
Expose at the last possible moment. Call .expose_secret() inline at the one call that needs plaintext, never at the top of a function. Audit every call site with grep -r expose_secret.
Give config structs a redacting Debug. Even with SecretString fields, a hand-written Debug documents intent and protects future non-secret fields from accidental dumps.
Keep secrets out of serde::Serialize. Do not let a config struct that holds secrets be JSON-serialized. If you must serialize a struct that contains a secret, write the impl by hand and skip the secret field.
Zeroize raw buffers you own. For decrypted plaintext or key-derivation scratch space you manage manually, use #[derive(ZeroizeOnDrop)] or call .zeroize() when done.
Prefer a secret manager over bare env vars for production: rotation, audit logs, and least-privilege access beat a static DATABASE_PASSWORD.
Scrub your logs, error responses, and panics too. A redacted Debug only helps if you log via Debug. Make sure error types and HTTP error bodies (see 28-production for observability) never embed exposed secrets.

Real-World Example

A production service config that combines every technique: load from the environment, wrap secrets in SecretString, redact the whole struct in Debug, fail closed if a required secret is missing, and expose plaintext only at the connection-string boundary.

1
cargo add secrecy
2
cargo add tracing tracing-subscriber

1
use secrecy::{ExposeSecret, SecretString};
2
use std::env;
3
use std::fmt;
4

5
/// All application configuration. Secrets are wrapped so they cannot leak via logs.
6
struct Config {
7
    service_name: String,
8
    bind_addr: String,
9
    database_password: SecretString,
10
    jwt_signing_key: SecretString,
11
}
12

13
impl fmt::Debug for Config {
14
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
15
        f.debug_struct("Config")
16
            .field("service_name", &self.service_name)
17
            .field("bind_addr", &self.bind_addr)
18
            .field("database_password", &"[REDACTED]")
19
            .field("jwt_signing_key", &"[REDACTED]")
20
            .finish()
21
    }
22
}
23

24
impl Config {
25
    /// Fail-closed loader: a missing required secret returns Err, never a default.
26
    fn from_env() -> Result<Self, String> {
27
        let get = |k: &str| env::var(k).map_err(|_| format!("missing env var: {k}"));
28
        Ok(Config {
29
            service_name: get("SERVICE_NAME")?,
30
            bind_addr: env::var("BIND_ADDR").unwrap_or_else(|_| "0.0.0.0:8080".into()),
31
            database_password: SecretString::from(get("DATABASE_PASSWORD")?),
32
            jwt_signing_key: SecretString::from(get("JWT_SIGNING_KEY")?),
33
        })
34
    }
35

36
    /// Build a connection string, exposing the password only here.
37
    fn database_url(&self) -> String {
38
        format!("postgres://app:{}@db/prod", self.database_password.expose_secret())
39
    }
40
}
41

42
fn main() {
43
    tracing_subscriber::fmt().without_time().with_target(false).init();
44

45
    // A real deployment sets these outside the process; set them here to run.
46
    unsafe {
47
        env::set_var("SERVICE_NAME", "billing-api");
48
        env::set_var("DATABASE_PASSWORD", "vault:db/prod#aB9");
49
        env::set_var("JWT_SIGNING_KEY", "vault:jwt/prod#Zx1");
50
    }
51

52
    let config = match Config::from_env() {
53
        Ok(c) => c,
54
        Err(e) => {
55
            // Note: the error mentions the var NAME, never a value.
56
            tracing::error!(error = %e, "failed to load configuration");
57
            std::process::exit(1);
58
        }
59
    };
60

61
    // Safe: secrets are redacted in the struct's Debug impl.
62
    tracing::info!(?config, "service starting");
63

64
    // Plaintext is exposed only inside database_url(), nowhere else.
65
    let url = config.database_url();
66
    tracing::info!(url_len = url.len(), "built database connection string");
67
}

Real output (ANSI colour codes stripped):

1
 INFO service starting config=Config { service_name: "billing-api", bind_addr: "0.0.0.0:8080", database_password: "[REDACTED]", jwt_signing_key: "[REDACTED]" }
2
 INFO built database connection string url_len=40

The startup log line — the one that leaks secrets in the Node version — is now safe, and the only place plaintext exists is the single format! inside database_url().

Exercises

Exercise 1: A self-redacting secret newtype

Difficulty: Beginner

Objective: Understand how a wrapper type controls its own Debug output.

Instructions: Without using the secrecy crate, write a newtype ApiToken(String) with a new constructor, an expose(&self) -> &str accessor, and a hand-written Debug impl that prints ApiToken([REDACTED N bytes]) (where N is the length) instead of the value. Prove with an assert_eq! that expose() still returns the real token.

Solution

1
use std::fmt;
2

3
struct ApiToken(String);
4

5
impl ApiToken {
6
    fn new(raw: impl Into<String>) -> Self {
7
        ApiToken(raw.into())
8
    }
9
    fn expose(&self) -> &str {
10
        &self.0
11
    }
12
}
13

14
impl fmt::Debug for ApiToken {
15
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
16
        write!(f, "ApiToken([REDACTED {} bytes])", self.0.len())
17
    }
18
}
19

20
fn main() {
21
    let token = ApiToken::new("sk-live-abc123");
22
    println!("{token:?}");
23
    assert_eq!(token.expose(), "sk-live-abc123");
24
}

Real output:

1
ApiToken([REDACTED 14 bytes])

This is exactly the principle SecretString automates: the default behaviour reveals nothing, and the only way to the plaintext is a named accessor.

Exercise 2: Wipe a buffer on drop

Difficulty: Intermediate

Objective: Use zeroize to clear a secret from memory deterministically.

Instructions: Add zeroize with the derive feature. Define a SessionKey struct holding a Vec<u8> and a String, derive Zeroize and ZeroizeOnDrop, construct one in an inner scope, use it, and let it drop. Then, in the same main, demonstrate a manual .zeroize() on a standalone String and print its length before and after to show it was cleared.

Solution

1
cargo add zeroize --features derive

1
use zeroize::{Zeroize, ZeroizeOnDrop};
2

3
#[derive(Zeroize, ZeroizeOnDrop)]
4
struct SessionKey {
5
    bytes: Vec<u8>,
6
    label: String,
7
}
8

9
fn main() {
10
    {
11
        let key = SessionKey {
12
            bytes: vec![0xAB; 16],
13
            label: "session-2026".into(),
14
        };
15
        println!("using key '{}' ({} bytes)", key.label, key.bytes.len());
16
    } // <- bytes and label overwritten with zeros here
17

18
    let mut token = String::from("temporary-token-xyz");
19
    println!("before zeroize: len = {}", token.len());
20
    token.zeroize();
21
    println!("after zeroize:  len = {}, value = {token:?}", token.len());
22
}

Real output:

1
using key 'session-2026' (16 bytes)
2
before zeroize: len = 19
3
after zeroize:  len = 0, value = ""

.zeroize() empties the buffer in place: the length drops from 19 to 0 and the bytes are overwritten.

Exercise 3: A fail-closed config loader with redacted logging

Difficulty: Advanced

Objective: Combine SecretString, a redacting Debug, and fail-closed loading into a realistic config type.

Instructions: Using secrecy, write a ServiceConfig with one plain field (port: u16) and one secret field (webhook_secret: SecretString). Provide a from_env() that returns Result<ServiceConfig, String> and fails if WEBHOOK_SECRET is missing or if PORT is missing/not a valid u16. Give it a Debug impl that redacts the secret. In main, set the env vars, load, log the whole struct, and then expose the secret once to print only its length.

Solution

1
cargo add secrecy

1
use secrecy::{ExposeSecret, SecretString};
2
use std::env;
3
use std::fmt;
4

5
struct ServiceConfig {
6
    port: u16,
7
    webhook_secret: SecretString,
8
}
9

10
impl fmt::Debug for ServiceConfig {
11
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
12
        f.debug_struct("ServiceConfig")
13
            .field("port", &self.port)
14
            .field("webhook_secret", &"[REDACTED]")
15
            .finish()
16
    }
17
}
18

19
impl ServiceConfig {
20
    fn from_env() -> Result<Self, String> {
21
        let port = env::var("PORT")
22
            .map_err(|_| "missing env var: PORT".to_string())?
23
            .parse::<u16>()
24
            .map_err(|e| format!("PORT is not a valid u16: {e}"))?;
25

26
        let webhook_secret = env::var("WEBHOOK_SECRET")
27
            .map(SecretString::from)
28
            .map_err(|_| "missing env var: WEBHOOK_SECRET".to_string())?;
29

30
        Ok(ServiceConfig { port, webhook_secret })
31
    }
32
}
33

34
fn main() {
35
    unsafe {
36
        env::set_var("PORT", "8443");
37
        env::set_var("WEBHOOK_SECRET", "whsec_3f9a1b7c2d");
38
    }
39

40
    let config = match ServiceConfig::from_env() {
41
        Ok(c) => c,
42
        Err(e) => {
43
            eprintln!("config error: {e}");
44
            std::process::exit(1);
45
        }
46
    };
47

48
    // Safe whole-struct log.
49
    println!("{config:?}");
50

51
    // Expose once, reveal nothing but the length.
52
    let len = config.webhook_secret.expose_secret().len();
53
    println!("webhook secret length = {len}");
54
}

Real output:

1
ServiceConfig { port: 8443, webhook_secret: "[REDACTED]" }
2
webhook secret length = 16

The loader fails closed (a missing or malformed value returns Err rather than a silent default), the secret is redacted everywhere it could be logged, and the plaintext is exposed at exactly one auditable site.

Secrets Management

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Why a wrapper type instead of a string

What SecretString actually is

Getting secrets in: environment variables

Loading a .env file in development

Secret stores and managers

Getting secrets out of memory: zeroize

Key Differences

Common Pitfalls

Trying to print a secret directly

Exposing too early and too widely

Forgetting that derived Serialize leaks

Putting secrets on the command line

Assuming zeroize guarantees erasure

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: A self-redacting secret newtype

Exercise 2: Wipe a buffer on drop

Exercise 3: A fail-closed config loader with redacted logging

Why a wrapper type instead of a `string`

What `SecretString` actually is

Loading a `.env` file in development

Getting secrets out of memory: `zeroize`

Forgetting that derived `Serialize` leaks