Free tool
Exposed secret checker
Enter your app’s URL to see whether it leaks an API key, token, or config in the code it serves to visitors. The single fastest way a fast-shipped app gets compromised is a secret that shipped to the browser by accident.
This check is passive. We read only the HTML and JavaScript your app already serves to any visitor. Detected secrets are redacted in the results.
Public key or leaked secret?
Not every key in your frontend is a problem. A Stripe publishable key and a Supabase anon key are meant to be public. A Stripe secret key, an AWS key, a database URL, or a private key never are. This checker separates the two so you are not chasing a false alarm, or missing a real one. For the deeper story on why secrets keep leaking, read the hardcoded secrets study and why env var secrets still leak.
Frequently asked questions
What does this exposed secret checker do?
It fetches your app's public URL and reads what the page serves to any visitor: the HTML and its JavaScript bundles. It then looks for secrets that should never be public, such as Stripe live keys, AWS keys, OpenAI and GitHub tokens, private keys, and exposed .env or .git files. Anything it finds is redacted in the results. The check is passive and never touches your server beyond a normal page request.
Which keys are actually dangerous to expose?
Secret keys are: a Stripe sk_live key, an AWS secret key, a database URL with credentials, a Supabase service_role key, or any private key. These give real access and must stay server-side. Some keys are public by design and safe to ship to the browser, like a Stripe publishable pk_live key or a Supabase anon key, which is only dangerous if Row Level Security is off. The checker distinguishes the two.
A secret was exposed. What do I do right now?
Rotate it at the provider immediately, because anything that shipped to a browser or a public repo should be treated as already compromised. Removing the line is not enough. Then move the secret into a server-side environment variable, and if it was committed to git, rotate rather than trying to scrub history. Assume any pushed secret was scraped.
The checker found nothing. Am I safe?
It is a good sign, but not a guarantee. A secret can live on a route the checker did not fetch, load only after a user action, or sit in your repository rather than your frontend. For the code that never reaches the browser, run a full repo scan in addition to this passive URL check.
The browser is only half the surface
This checks what your live app serves. A full Prbl scan also reads your repo for the secrets and missing auth checks that never reach the browser, and rewrites the fix for you.
Run a free scan