Environment variables and secrets: where they should never be

The short answer

A secret is any value that grants access: an API key for the email service, a database password, a token for the automation platform, a signing key for webhooks. Wherever a secret is stored, whoever can read that place holds that access, which is why where secrets live matters more than how long or random they are. During audits of inherited sites we find secrets in repositories, current and historical, in front-end code every visitor downloads, in build and deployment logs, in chat messages, in shared documents and spreadsheets, in screenshots and in the environment files developers keep on laptops. Each is a leak waiting to be found, and several are found routinely by automated scanners. Secrets belong in one place: the platform’s secret storage, injected into the running function or the build, scoped per environment, with access limited to named people and never printed. A secret found anywhere else is revoked and replaced immediately, and the place it leaked from is fixed.

Where we find secrets and why each is dangerous

Where	Why it is there	Why it is dangerous
Committed in the repository	Convenience during development	Every clone, fork, backup and past collaborator has it; history keeps it after removal
In front-end JavaScript	The developer called the API from the browser	Every visitor downloads it; it is public
In build or deployment logs	A script printed configuration	Logs are kept, shared and rarely protected
In chat messages and email	Shared quickly between colleagues	Searchable forever, in accounts that get compromised
In shared documents and spreadsheets	The team’s password list	Wide access, no audit, copied everywhere
In screenshots	Documentation or a support ticket	Stored in image libraries and tickets indefinitely
In environment files on laptops	Local development	Lost or stolen devices; synced to cloud folders
In a content system’s settings pages	A plugin wanted a key	Readable by every admin; often exposed by plugin flaws
In error messages on the site	Verbose errors in production	Shown to whoever triggers the error

The rules

Public keys and real keys

Some values are designed for the browser: a payment provider’s publishable key, an analytics measurement identifier, a map key restricted to your domain. They can be in front-end code because they cannot do harm on their own or are restricted to your site. The test is what the value can do if a stranger has it. If it can send, charge, read, write or delete, it is a real secret and belongs in secret storage behind a function.

What this means for you

Secrets grant access to whoever can read where they are kept. Keep every one in the platform’s secret storage, per environment, with named access; keep front-end code free of anything that can act; keep repositories, logs, chats, documents and screenshots free of them; scope each key narrowly; scan continuously; and treat any secret found elsewhere as leaked and replace it. The discipline costs nothing and removes the most common way a small business hands its accounts to strangers.