Glossary
Environment variable
An environment variable is a named value supplied to a program by its environment rather than written into its source, which is how the same code runs against a development database and a production one. In front-end build tooling the term acquires a second meaning: variables carrying a designated prefix are deliberately inlined into the browser bundle at build time, which makes them public by construction and is the source of the most common credential leak on the web.
Two kinds, and the prefix that separates them
Server-side variables are read by the process at runtime and never leave it. A database password belongs here.
Build-time public variables carry a prefix the bundler recognises, and their values are substituted into the JavaScript that ships to every visitor.
The prefix is an instruction, not a hint: it tells the bundler to publish the value. A variable behind one is not a secret by definition.
Every major front-end framework uses this pattern with its own prefix, which is why the convention is worth knowing regardless of which one a site uses.
How a private key ends up behind a public prefix
A developer needs a value at build time. The build fails because the variable is undefined in the browser context.
Adding the prefix makes the build succeed, and nothing about the running site looks different.
The value is now in a file served to everyone, and it stays there for every deployment until someone reads the bundle.
Which is why the names are worth reviewing: a name describing a publishable identifier is fine, and one containing a server-side key convention is not.
When one is found, renaming the variable is not the fix. The value has been public for an unknown period and has to be rotated.
What is observable from outside
The names of public-prefixed variables referenced in the served pages. Names only — values are neither read nor displayed.
The name is what carries the signal, because it is what tells you whether something with a server-side purpose was given a public prefix.
Actual credentials found inside served files are a separate check, which distinguishes keys designed to be public from keys that are not.
Server-side variables are invisible from outside by construction, which is the whole point of keeping them there.
Where the values should live instead
In the deployment platform's own secret storage, injected at runtime and never written to a repository.
Not in a committed file, even one excluded from the build, because repository history keeps a file long after it is deleted.
Not in a public prefix, unless the value is genuinely meant to be readable by every visitor.
A secret scanner in the build pipeline catches what an external inspection cannot, and it catches it before the value is ever served.
Frequently asked questions
- Is a variable behind a public prefix a secret?
- No, and it is not treated as one. The prefix instructs the bundler to publish the value. The finding is a value that should have been server-side being given one.
- Do you read the values of my public variables?
- No. Only the names are collected, because the name is what reveals a server-side purpose behind a public prefix. Values are never read or displayed.
- I removed the key from my code. Is that enough?
- No. It was served publicly for an unknown period, so it must be rotated. Removing it prevents future exposure and does nothing about copies already taken.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website