Free frontend env variable leak checker
Anything your build tool bundles into browser JavaScript is public, including environment variables with a VITE_, NEXT_PUBLIC_, REACT_APP_ or EXPO_PUBLIC_ prefix. This checks whether your live site ships a secret key to every visitor.
What this checks
- Secret keys in your page and JavaScript: the HTML, inline scripts and up to 20 same-origin JavaScript files your page loads (plus files those reference). It looks for Supabase service_role and
sb_secret_keys, OpenAI, Anthropic, xAI, Groq, OpenRouter, Replicate, Stripe secret and webhook keys, SendGrid, Resend, AWS, GitHub and Slack tokens, private keys and database URLs with a password. - Public env variable names: the
VITE_,NEXT_PUBLIC_,REACT_APP_andEXPO_PUBLIC_names that appear in your served code (names only), with a warning for names that sound server-only, likeSECRET,SERVICE_ROLE,PRIVATEorPASSWORD. - Keys that are meant to be public, like the Supabase anon or publishable key and a Firebase web config, are noted as normal, not as problems.
What it can't tell you
- Keys and where they were found aren't shown on this page. If it lists one, rotate it. Owners who verify their site can see the masked key and its file in a full scan.
- It reads JavaScript on the site you enter, not scripts from other domains or code that only loads after sign-in or a click.
- It recognizes the key formats listed above. A secret in an unusual format, or split across strings, can be missed.
- A variable name alone isn't proof of a leak: a
NEXT_PUBLIC_..._SECRETmight hold something harmless. Check its value. - It checks live web URLs only, not native mobile apps or pages behind a login.
- No issues found means none in this one check at that moment. It is never proof of security.
Check it yourself
Open DevTools → Sources on your live site and search all files (Ctrl+Shift+F or Cmd+Option+F) for sk_live_, service_role, sb_secret_ and sk-. Or from a terminal:
curl -s https://your-app.com/ | grep -o 'src="[^"]*\.js"' curl -s https://your-app.com/assets/index-abc123.js | grep -oE '(VITE|NEXT_PUBLIC|REACT_APP)_[A-Z0-9_]+' | sort -u
Use your own JavaScript file path from the first command. Any value you can read this way, every visitor can read too.
How to fix it
- Rotate any secret key it finds at the provider first. Removing it from the code doesn't un-publish the old one.
- Move the secret to a server-only variable (no public prefix) and call the provider from a server route, edge function or Supabase Edge Function instead of the browser.
- Redeploy, then check again.
This checker answers one question. The free scan checks everything at once, and how our scanner works explains what it does and never does.
Questions
Is my Supabase anon key a leak?
No. The anon or publishable key is designed to be public; Row Level Security is what protects your data. The service_role and sb_secret_ keys are the ones that must never reach the browser.
Why don't you show the key you found?
So this page can't be used to collect other people's keys. It tells you what kind of key it is so you can rotate it. Owners who verify their site see the masked key and its file in a full scan.
Does putting a key in an env variable keep it secret?
Only if it stays on the server. Build tools copy variables with a public prefix (VITE_, NEXT_PUBLIC_, REACT_APP_, EXPO_PUBLIC_) into the JavaScript every visitor downloads.
Do you use any key you find?
No. This check never sends, tests or stores a key.