Environment variables and secrets: where keys should live
API keys, tokens and passwords are what connect your site to other services. Where they belong, where they must never be, and how to check in five minutes.
The short answer
A secret is any value that grants access to something: the key for the email service, the token for the CRM, the database password, the signing key for sessions. A website needs several, and where they live decides whether they stay secret. They belong in the hosting platform’s encrypted configuration, provided to the code as environment variables at build or run time, separately for preview and production. They must never be in the code repository, in the files the browser downloads, in chat, in email or in a shared document. Anything that reaches the browser is public, whatever it is called.
Where secrets belong, and where they must never be
| Location | Secrets allowed? | Why |
|---|---|---|
| Platform configuration, encrypted, per environment | Yes | Encrypted at rest, scoped, auditable, not in code |
| Company password manager | For human use and as backup | Controlled access, shared without copying |
| Code repository | Never | History is forever; clones are everywhere; leaks are routine |
| Front-end code and the built site | Never | Everything the browser downloads is public |
| Chat, email, documents, tickets | Never | Copied, searched, forwarded, retained |
| A developer’s laptop only | Never as the sole copy | Continuity and security both fail |
The five-minute check
- Search the repository history for key-shaped strings and the names of your providers. History counts, not just the current files.
- Search the built site as a visitor would: view source, open the scripts, search for the same patterns.
- Open the platform’s configuration and confirm every secret is there, marked sensitive, with separate values per environment.
- Confirm the front end uses only public keys intended for browsers, with restrictions set at the provider where possible.
- Check who can read the configuration: named people, two-factor, no shared accounts.
Separating environments
Preview deployments and staging should use their own keys: test mode at the payment provider, a sandbox CRM, a test email destination. Then a preview of a form change never sends a real email or creates a real record, and a leaked preview key exposes nothing real. Production keys are set only in production, read by as few people as possible, and rotated on a schedule and whenever a person with access leaves.
What this means for you
Your website’s keys are as sensitive as your bank login, and they are handled far more casually than that. Insist that they live only in the platform’s encrypted configuration and a company password manager, separately per environment, never in code, never in the browser, never in chat. Run the five-minute check once. It is the cheapest security review a website can have.
Frequently asked questions
We put the API key in the code because it was easier. How bad is that?
It depends on where the code went. If the repository is private and the key was never in the built site, remove it, move it to the platform's configuration and replace the key at the provider. If the repository is public or the key was shipped to browsers, treat it as compromised now and replace it today; scanners find exposed keys within minutes.
What is the difference between a build-time and a run-time secret?
A build-time secret is used while the site is being built, for example to fetch content from a CMS, and never reaches the browser. A run-time secret is used by a function while serving a request, for example to send an email. Both live in the platform's configuration; the distinction matters for what the key may be used for and where it could leak.
How do we know if a key has leaked?
Providers often notify you when they detect a key on a public site or repository, and usage dashboards show unexpected activity. Do not wait for either: search the repository history and the built site for key patterns once, and assume anything that was ever in front-end code is known.
Sources
- OWASP Cheat Sheet Series: Secrets Management (accessed 2026-09-11)