VibeSecurity

Free tool, runs in your browser

Is any secret in a public environment variable?

Frameworks copy variables with certain prefixes into the code every visitor downloads. Paste your variable names to see which ones should never carry that prefix.

Paste names only. If you paste NAME=value lines, the value is discarded as you type and never stored or sent anywhere. Do not paste real secrets.

7 variables checked, 1 exposed secret found

  • NEXT_PUBLIC_SUPABASE_URLPublic by design

    Browser-exposed by design. Fine only if the value is safe to print on your homepage.

  • NEXT_PUBLIC_SUPABASE_ANON_KEYPublic by design

    Browser-exposed by design. Fine only if the value is safe to print on your homepage.

  • NEXT_PUBLIC_OPENAI_API_KEYExposed secret

    Has a browser-exposed prefix but looks like a secret. Anything with this prefix is inlined into the public bundle. Rotate it if it was ever deployed, and move it to server-only configuration.

  • SUPABASE_SERVICE_ROLE_KEYServer-only

    Looks like a secret. Keep it in server-only configuration, never in client code, a public-prefixed variable or the repository.

  • STRIPE_WEBHOOK_SECRETServer-only

    Looks like a secret. Keep it in server-only configuration, never in client code, a public-prefixed variable or the repository.

  • DATABASE_URLServer-only

    Looks like a secret. Keep it in server-only configuration, never in client code, a public-prefixed variable or the repository.

  • VITE_APP_NAMEPublic by design

    Browser-exposed by design. Fine only if the value is safe to print on your homepage.

Which prefixes expose a variable

Rename a variable and rebuild, and the old value can still live in earlier deployments, cached bundles and your repository history.

FrameworkPrefix that reaches the browserWhere it is inlined
Next.jsNEXT_PUBLIC_Client bundles, at build time
ViteVITE_Client bundle, at build time
ExpoEXPO_PUBLIC_The app bundle
Create React AppREACT_APP_Client bundle, at build time

If the tool flags an exposed secret

  1. 1Create a new key at the provider and revoke the old one. Removing it from code is not enough.
  2. 2Move the call that needs the secret into a server route or function and read the key from a server-only variable.
  3. 3Redeploy, then search the built JavaScript for the old value to confirm it is gone.
  4. 4Check the provider's usage logs for activity you do not recognise.

How the checker decides

It reads only the variable name. A browser-exposed prefix combined with words such as secret, token, password or service role is flagged. Names that are usually public, such as a database project URL or a publishable payment key, are marked public by design. Names it cannot classify are marked for review. It is a name-based hint, not a scan of your app.

Frequently asked questions

Does this tool see my secret values?

No. It works from variable names. If you paste NAME=value lines, the value is dropped as you type and is never stored or sent anywhere.

Is a NEXT_PUBLIC_ key always a leak?

No. Some keys are designed to be public, such as a Supabase anon key or a Stripe publishable key, because access is limited by rules on the server side. A secret key with a public prefix is a leak.

Why is my variable marked Review?

The name does not tell the tool what it holds. Ask what someone could do with the value. If the answer is anything harmful, keep it server-only.

Sources

  1. 1.Next.js docs: Environment variables
  2. 2.Vite docs: Env variables and modes
  3. 3.Supabase docs: API keys
  4. 4.Stripe docs: API keys