Secret-named public environment variable is assigned in client code
ShipReady found a browser-exposed environment-variable name containing a secret-related term and assigned a value in client-side JavaScript.
Why it matters
Build prefixes such as NEXT_PUBLIC and VITE intentionally publish a value to browser assets, so they are unsuitable for confidential credentials.
How ShipReady detects it
What it inspects
ShipReady reads client-side executable content for supported browser-public environment-variable prefixes, a secret-related variable name, and an assigned value.
What triggers a finding
The rule triggers when all three signals occur together. It excludes known intentionally public values such as Supabase anon keys, Stripe publishable keys, analytics identifiers, URLs, and name-only mentions.
What the evidence shows
A secret-named browser-public variable was assigned a value in observed client content. The report records the variable name, never the value.
Limits of this check
ShipReady does not identify the provider from the value, validate the value, connect to a service, or determine whether it is active. The variable name is a risk signal, not proof that the value is a usable secret.
How to fix it
Move confidential configuration server-side
Remove the value from browser-public environment variables and supply it only to trusted server code.
Review build-time inlining
Audit deployment configuration and generated assets because removing a prefix does not remove a value already shipped in a prior build.
How to verify the change
Search the production bundle
Inspect generated JavaScript for the variable name and confirm no confidential value is inlined.
Expected: Browser-public variables contain only intentionally public values.