What should I do if I find an API key in my frontend bundle?

Issue a new credential and revoke the old one. Every minute the old key remains valid is a minute it can be used.

Assume it was copied. Bundles are cached by browsers, mirrored by third parties, and indexed by anything that crawls JavaScript.

Check the provider's logs for use from addresses you do not recognise, before and after rotation.

Do not rotate by deploying a new bundle first and revoking later — that publishes the new key alongside the old one.

Some keys are designed to be public: a publishable payment key, a maps key, a Supabase anon key. These identify the project and are protected by server-side rules rather than by secrecy.

A public key is only safe when the restrictions behind it are configured — origin allow-lists, referrer restrictions, row-level security, per-key scopes.

Everything else — a secret API key, a database credential, a signing key, a service account — must never reach the browser under any circumstances.

If the front-end needs data that requires a secret, the call belongs on the server and the browser calls your server instead.

The test is simple: would you publish this value in a public repository? If not, it cannot be in the bundle.

A build-time environment variable with a public prefix, which is exactly what those prefixes mean and is easy to apply to the wrong variable.

A configuration object shared between server and client code, where one field was secret and nobody separated them.

A hard-coded value added during development and never replaced.

A third-party snippet copied from documentation that included a real key.

A source map published alongside the bundle, which turns a minified constant into readable named code.

Scan the build output rather than the source. The bundle is what ships, and it is the only artefact that matters for this.

Add a secret-scanning step to the pipeline that fails the build rather than reporting afterwards.

Keep secret and public configuration in separate files with different naming conventions, so mixing them requires a deliberate act.

Do not publish source maps to the public server. Upload them to the error-tracking service instead, which keeps readable stack traces without publishing the code.

Rotate anything that was ever committed to a repository, even a private one, on the same assumption.

VeriFixScan reports `exposure.secrets.private` for credential-shaped strings found in public files, and `exposure.secrets.public_keys` for the publishable kind that are expected to be there.

The distinction matters: reporting a publishable payment key as a leak is noise, and missing a secret key because it looked similar is the failure that counts.

`exposure.sourcemap.public` and `exposure.sourcemap.sources_content` report whether the readable source was published alongside the bundle.

A scan reads what is publicly fetchable. A secret in server-side code, in an environment variable, or in a private repository is outside what it can see — and none of those are exposures by themselves.