Production Secret Management: Inject, Don't Store
Treat secrets like temporary credentials, injected at runtime, not stored with your code. This applies to database passwords and API keys in production. The biggest footgun is using .env files; they are a dev convenience, not a security model.
Why it exists
Applications need secrets like database passwords and API keys. Storing them directly in code or in .env files is a huge risk. They are often accidentally committed to Git, exposed in logs, or left in plaintext on a server's filesystem, where a single leak can lead to a full system breach.
The mental model
Secrets should never be stored with your application code. Instead, they should be injected into the running process at startup. Think of them as temporary, runtime-only credentials, not as static configuration files. The application code itself should be completely unaware of where the secrets came from.
How it works
There are three primary patterns for getting secrets into a running application. First, platform-level injection, where your hosting environment (like Kubernetes, Heroku, or ECS) provides secrets as environment variables. Second, API fetch at startup, where the app calls an external service like AWS Secrets Manager or HashiCorp Vault to retrieve secrets when it boots. Third, a sidecar pattern, where a companion container writes secrets to a temporary, in-memory filesystem for the app to read.
When to use it
Always use a formal secret management strategy in any production or staging environment. It is non-negotiable for any application handling database credentials, third-party API keys, or JWT signing tokens. Platform injection is the simplest method if your hosting provider supports it. API fetch is better for complex key rotation requirements or serverless functions.
When not to use it
The only environment where this level of security is often bypassed is local development. Using a .env file on your local machine is acceptable for convenience, as the risk of exposure is low. However, you must ensure your .gitignore file is correctly configured to prevent these files from ever being committed to source control.
One canonical example
For platform-level injection in Node.js, the app reads secrets from process.env. A robust application will validate their presence at startup. It checks for all required keys, and if any are missing, it logs the names of the missing keys (never their values!) and immediately exits with an error. This "crash-on-boot" approach prevents the application from running in an insecure or misconfigured state.
Interview question
What is the primary risk mitigated by injecting secrets at runtime instead of storing them with application code?
- a.The risk of performance degradation due to frequent secret lookups during application execution.
- b.The risk of secrets being accidentally committed to source control or exposed in logs.Correct
- c.The risk of secrets expiring and requiring manual updates in the codebase.
- d.The risk of unauthorized access to secrets by developers during local development.
Why? this is the answer
The card explicitly states that storing secrets directly in code or .env files is a huge risk because they are "often accidentally committed to Git, exposed in logs, or left in plaintext on a server's filesystem." Injecting them at runtime directly mitigates these exposure risks. Option D is incorrect because the card notes that using .env files for local development is acceptable due to low risk, provided .gitignore is configured, indicating the primary concern of injection is not local developer access but production exposure.
Just read this? Test yourself on what you have been reading.
Read the original → dev.to
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on security — each one lists the topics its interview covers.
See open roles