A frontend environment variable is not a secret API key
Check the browser bundle and network requests, move privileged calls to a server and rotate a key if it has already shipped.
In brief
Anything delivered to a browser can be inspected by the person using it. A build-time environment variable can become a literal value in JavaScript, so its name does not make a privileged API key secret.
This distinction prevents paying for another person’s API use or exposing data through a credential copied from your website.
Trace the value to the browser
Check where the build tool substitutes configuration and what the request sends. Source maps, bundled text and network headers can expose a value even when the source variable had a reassuring name. Test your own project locally and avoid sharing screenshots containing the secret.
Put privilege behind an actual boundary
A server or Worker can hold the secret and make the provider call, but it also needs authorization, input validation and usage limits. An unauthenticated proxy forwarding arbitrary requests merely moves the billing risk. Keep the public endpoint limited to its intended action.
Treat a shipped key as exposed
Remove it from the client, revoke or rotate it at the provider and review usage. Removing it from the current page or Git commit does not invalidate copies already obtained. Use the platform’s server-side secret facility and keep local secret files out of published assets and version control.
Before you act
Some services deliberately use public client identifiers with restricted capabilities. Distinguish those documented identifiers from secrets granting billing, administration or private-data access.
What to do next
- Classify each credential using the provider’s documentation.
- Inspect built JavaScript and browser requests for privileged values, without pasting them into public tools.
- Move secret-bearing calls to a controlled server and revoke exposed credentials before issuing replacements.
