Secret keys hiding in
your shipped JavaScript.
Every time you deploy, your JS bundle goes public. We read it for API keys, leftover .env files, source maps that point back to your code, open admin panels, and missing security headers. Before someone else gets there first.
Couldn't reach that URL
Make sure the app is live and publicly accessible, then try again.
Your bundle ships everything you told your AI assistant to write.
API key patterns
We scan your JS bundles for known key shapes: Stripe sk_live_, OpenAI sk-proj-, AWS AKIA, Supabase service role keys, and 20+ more.
.env file remnants
We check whether /.env, /.env.local, and /.env.production are sitting there publicly at your domain.
Source maps
We check whether .js.map files are served publicly. Source maps hand your full unminified code to anyone who looks.
Exposed admin panels
We poke common admin paths (/admin, /dashboard, /_admin) and check whether they render without bouncing logged-out visitors.
Security headers
We check response headers for CSP, X-Frame-Options, HSTS, X-Content-Type-Options, and Referrer-Policy. Required for PCI DSS and basic compliance.
Robots.txt and sitemaps
We read your robots.txt for paths you've leaked by accident, and check whether any Disallow rules hint at routes you'd rather keep quiet.
Common questions
How do API keys end up in client bundles?
AI assistants love to drop keys straight into component files. Vite and Next.js will bundle any process.env.* reference that isn't prefixed with VITE_ or NEXT_PUBLIC_ correctly. Easy to do, almost impossible to catch by reading your own code.
I found a key. What do I do first?
Revoke it right away from the provider's dashboard, then replace it. Treat any exposed key as compromised whether or not you've seen misuse. Attackers index GitHub and public bundles around the clock.
Is it safe to have API keys in client-side JavaScript?
Public keys like Supabase anon keys belong in the browser and rely on Row Level Security for protection. But secret keys (service role keys, Stripe secret keys, OpenAI keys) should never appear in client-side code. If they do, anyone can use them.
Can someone see my source code through source maps?
Yes. If your production build includes .js.map files, anyone can download your original source code, including comments, internal logic, and potentially hardcoded secrets. Most frameworks generate source maps by default. Leak Radar checks if yours are publicly accessible.
Are source maps always a problem?
Not always. Some teams serve them on purpose. But for most apps, shipping source maps in production gives attackers your full business logic, internal paths, and every comment your AI assistant left behind.
What happens if my Supabase service role key is exposed?
The service role key bypasses all Row Level Security policies. Anyone with it can read, write, and delete any data in your database. Rotate it immediately in the Supabase dashboard and move it to a server-side environment variable.
Do you store the keys you find?
No. We surface them in your report and nowhere else. We never store, log, or share the secret values we find. Only the file path and a truncated pattern used to spot them.
What is the difference between Leak Radar and a full security scan?
Leak Radar checks what is visible from the outside: exposed keys, files, and headers. A full LaunchGuard scan goes deeper: it crawls every endpoint, tests database access controls, checks for unprotected APIs, and gives you findings with live evidence.