We shipped an API key in our frontend bundle. It took nine months for someone to notice, and abuse it.
The security boundary is "does this ever reach the browser," not "is it in an env file." Client-reachable code needs scoped, revocable keys or a backend proxy.
security
Problem
A third-party service key got hardcoded into a config file that ended up in our client-side JavaScript bundle. It worked fine in every test we ran, because it was supposed to be callable from the browser. Nine months later, someone scraped it out of our bundle and used it to run six figures’ worth of API calls on our account.
Why it happens
“It’s in an environment variable” feels safe, and most side-project setups don’t distinguish between a variable that’s safe to expose to a browser and one that isn’t. If the build step just ships every process.env value into the client bundle, the browser can read it, and so can anyone who opens dev tools.
Better approach
Treat “does this ever reach the browser?” as the security boundary, not “is it in an env file.” Anything callable from client code needs scoped, revocable, rate-limited keys, or better, a thin backend proxy that holds the real credential server-side and never ships it.
Example
We rebuilt the integration behind a small backend route that added the real key server-side. The client now sends a request to us, we forward it with the credential attached, and the key never leaves our servers again.