I've written repeatedly about moving keys out of frontend code into environment variables as the fix for exposed secrets. It's the right fix, and I stand by recommending it constantly. It's worth being clear, though, that "it's an environment variable now" is a meaningfully safer state, not an automatically safe one, and there are a few ordinary ways that safety gets undone.
Where env variables still leak, even when handled correctly at first
- Detailed error pages, the same information-leakage issue I've written about before, sometimes print out environment details or configuration dumps as part of a stack trace, handing over exactly the values you moved server-side specifically to protect.
- A debug or health-check endpoint, built to help during development, that echoes back configuration values or environment details, left reachable in production because nobody remembered it exposes anything sensitive.
- Logging that captures more than intended: a request or response gets logged in full for debugging purposes, and if that request happened to include or reference an environment value somewhere in the process, it's now sitting in a log file, possibly one with far looser access controls than your actual application.
- A build process that accidentally bundles a server-side environment variable into client-side code, which happens more often than people expect with frameworks that have both server and client environment variable conventions, if the naming convention that marks a variable as safe for the browser gets used by mistake on something that shouldn't be.
Why that last one specifically deserves attention
Several popular frameworks distinguish between server-only environment variables and ones explicitly meant to be exposed to the browser, often through a naming prefix convention. Using that prefix on a variable that shouldn't be public, out of habit, a copy-paste mistake, or simply not knowing the distinction exists, ships the value straight to the browser bundle, the exact outcome moving it to an environment variable was meant to prevent in the first place.
What actually closes the gap
- Confirm your production error handling doesn't print environment details, the same check from the error-page post applies directly here.
- Search your frontend build output for the actual values of your sensitive environment variables, not just for the word "key" or "secret", to catch a naming-convention mistake that bundled something server-side into the client.
- Review what your logging actually captures, and whether any of it could include sensitive configuration values in full requests or error dumps.
- Remove or properly protect any debug or health-check endpoint before it goes to production, rather than assuming it's harmless because it was only meant for development.
Moving a secret into an environment variable is genuinely the right first step, and it closes off the most common way keys leak. It's not a single action that permanently solves the problem, it's a state that needs to actually hold up against error pages, logs, debug endpoints, and build processes that can each, in their own ordinary way, undo it.