Is your API key in your website's JavaScript?

Check your build before you deploy

Add this after the build step in CI. It fails the job if a key-shaped string is in the output (use .next/static for Next.js):

! grep -rEq '(^|[^A-Za-z0-9])(sk-[A-Za-z0-9_-]{20,}|AIza[0-9A-Za-z_-]{35}|sk_live_[0-9A-Za-z]{24,})' dist/

Questions

How do API keys end up in a website's JavaScript?

Build tools copy some environment variables into the code sent to browsers. In Vite that's any VITE_ variable, or anything in a define block (Google AI Studio exports do this with GEMINI_API_KEY). In Next.js it's any NEXT_PUBLIC_ variable. Once built, the key is in a file every visitor downloads.

What does this checker look at?

The page you enter and the JavaScript files it loads from its own site: the same files any visitor's browser downloads. It doesn't log in, follow links to other pages, or see your server or repository.

Is it safe to check my site here?

Results show only the provider, the key's public prefix and its length, never the key itself, and nothing about the site or the result is stored. Anything this tool can see, anyone can already see by opening your site's DevTools.

It found an AIza key from Firebase. Is that a leak?

Firebase web config keys are public by design. The risk is when the same key can also call paid APIs such as Gemini. In Google Cloud, restrict the key to the Firebase APIs it needs, and use a separate key for Gemini that never ships to the browser.

It found a key. What now?

Rotate it immediately and check the provider's usage page, because scanners find exposed keys within minutes. Then move the call to a server function, or give the browser a capped, revocable token instead of the key.