How do I know if my API key is exposed?

Open your live app, then open the browser's developer tools and look at the JavaScript it downloads. If a secret key is in there, it is exposed, because anything the browser downloads, any visitor can read.

That manual check works but is easy to get wrong, because keys hide inside large minified bundles. A scanner does the same thing more thoroughly: it reads your live JavaScript and matches it against known key formats for Stripe, OpenAI, AWS, Supabase, and more.

One nuance worth knowing: not every key is a secret. A public key that is designed to ship (like the Supabase anon key) is fine. The ones that matter are secret keys and service keys, which should only ever live on your server.

Scan your app for exposed keys

It flags secret keys, not public keys that are designed to ship, and shows where each was found.

What it means

A value shaped like a private key or password is in code your site serves, where anyone can read it. If it still works, anyone who copies it can act as you: run up bills, read your data, or send email in your name. xlogs did not test it.

Why AI tools cause it

AI coding tools often paste an API key straight into a file to make something work, instead of hiding it in a private environment variable. It runs fine, so nothing warns you.

How xlogs checks it

xlogs scans your live JavaScript against 18 key formats covering Stripe (live, test and webhook secrets), OpenAI, Anthropic, AWS, Google, GitHub, Slack, private key blocks, and Supabase server keys (service_role and sb_secret_).

How to fix it

The goal: The exposed key has been replaced and revoked at the provider, because removing it from the code does not stop it working, and the new value is stored only in a server-side secret or environment variable, never in code or the client bundle.

  1. Contain and rotate the exposed key first, because removing it from the code does not stop it working: if you suspect it is being misused, revoke it at the provider now; otherwise create a replacement, put it in the app's server-side secret settings, confirm the app works with it, and then revoke the exposed key promptly
  2. Remove the literal value from the code and any client-side bundle (the affected spot), so the key is read only from a server-only environment variable
  3. Make sure the .env file is in .gitignore
  4. Clear the old value from deployed builds and caches, and from the repository's history where you can; once the key is revoked, a copy left there no longer works
Paste this to your AI coding tool (Lovable, Cursor, Claude Code):
In my app (the spot the scan shows): a credential-shaped value is publicly served. Please make this true: The exposed key has been replaced and revoked at the provider, because removing it from the code does not stop it working, and the new value is stored only in a server-side secret or environment variable, never in code or the client bundle. Steps: Contain and rotate the exposed key first, because removing it from the code does not stop it working: if you suspect it is being misused, revoke it at the provider now; otherwise create a replacement, put it in the app's server-side secret settings, confirm the app works with it, and then revoke the exposed key promptly; Remove the literal value from the code and any client-side bundle (the spot the scan shows), so the key is read only from a server-only environment variable; Make sure the .env file is in .gitignore; Clear the old value from deployed builds and caches, and from the repository's history where you can; once the key is revoked, a copy left there no longer works. Then tell me exactly what you changed, and do not print any secret values back to me or write one into a commit message, a pull request description or a log.

Then verify: After you deploy the fix, xlogs re-scans your live app and reports whether the key is still found in what it reads. That cannot show the old key was revoked, so revoke it at the provider either way.

Common questions

I found an exposed key. Is deleting it from the code enough?

No. The old value is already public, so assume it is compromised. Rotate (regenerate) it at the provider first so the exposed copy stops working, then move it to a server-only environment variable and remove it from the code and bundle.