How should a Rust application handle secrets?

Rust's memory safety does not stop secrets from leaking into logs, error messages or serialized output. Wrap passwords and keys in a type such as SecretBox from the secrecy crate, make every read explicit, wipe memory on drop with zeroize, and keep the secrets out of source control and process arguments.

What is Rust protecting you from, and what not?

The compiler prevents use after free and buffer overflows. It does not know that a String holds an API token. The usual leak paths are plain: a derived Debug implementation on a struct that contains a password, a debug format specifier in a log line, an error type that embeds a request including its headers, or a serializer that writes every field.

What does the secrecy crate do?

Its documentation says it provides a SecretBox wrapper type for handling secret values such as passwords, keys and access tokens. Its stated goals:

1. Make secret access explicit and easy to audit through the ExposeSecret and ExposeSecretMut traits.
2. Prevent accidental leakage through channels like debug logging.
3. Ensure secrets are wiped from memory on drop, using the zeroize crate.

Two details matter in code review. With the serde feature on, SecretBox can be deserialized, which lets you load a secret from config. But by default it has no Serialize implementation, to prevent exfiltration through serde. You have to opt in with a marker trait, so any such opt-in is a review flag. And the docs warn to clean up intermediate secrets when deserializing, for example the unparsed input.

A constructed example: a service reads config.toml into a struct with a db_password: String. A startup log prints the config with {:?}. The password lands in a log aggregator. Changing the field to SecretBox makes the debug output hide the value, and any code that wants the real value must call expose_secret(), which shows up in a search.

What does zeroize do, and where does it stop?

Zeroize documents that zeroing memory securely is hard because compilers optimize away zeroing calls, and it uses techniques that guarantee the write is not removed. That helps limit how long a secret lives in memory.

The limits are honest. The secrecy docs say the crate does not provide more advanced memory protection such as mlock or mprotect, and suggests another crate for those who accept the std and libc dependencies. Copies made before wrapping, in buffers, in the allocator's reused memory or in a swap file, are outside what the wrapper controls. Treat it as defense in depth, not a vault.

Where should the secrets come from?

OWASP's secrets management guidance says many organizations hardcode secrets in source and configuration files, and calls for centralized storage, provisioning, auditing and rotation. For a Rust service that means loading from a secret manager or a mounted file at start, not from a committed file and not from command line arguments, which other users on a host can see in process listings. OWASP also describes dynamic secrets that expire with a lease, which reduces the value of a leak.

What to do

1. Search for fields named password, token, key and secret that use plain String or Vec<u8>, and move them to SecretBox.
2. Make sure Debug output on config structs never prints secret fields, and confirm with a test that formats the struct.
3. Search for expose_secret and review each call site, since it is the only place the value is revealed.
4. Do not enable Serialize for secret types unless you can name the consumer.
5. Load secrets from a manager or mounted file. Rotate on a schedule and after any suspected exposure.
6. Add secrets scanning to CI. Safeguard's secrets scanning can flag committed credentials before merge.
7. Use cargo audit or equivalent to watch the crates themselves for advisories.

Quick check

Sources

1. secrecy crate documentation
2. zeroize crate documentation
3. OWASP Secrets Management Cheat Sheet

Last reviewed: 18 October 2026.