Is a secret key sitting in my website?
Keys for payments, email, text messages and databases are meant to live on your server, where a visitor cannot see them. An AI tool will sometimes put one in the code your site hands to every browser.
Free. No sign-up. We check the one page you give us, and only what any visitor can already see.
This sees what your public site exposes. To also read the app’s source history we would need you to connect the code, which unlocks a deeper version of this check. A clean result here means nothing dangerous is in what a visitor can see.
Nobody chooses this. It is what is left out.
There are two kinds of key and they look almost identical. One is meant to be public and every app built this way ships one; the other unlocks your money. Told to "add the key so it works", a tool reaches for whichever one makes the error go away, and both make the error go away.
Nothing breaks when the wrong one goes out. The app works perfectly, which is the problem: the only signal that anything happened is the charge on your card, or an email nobody at your company sent.
We read what your site actually sends to a browser and pull out anything shaped like a key, then work out which kind it is before saying a word. A key that is supposed to be public is reported as exactly that, and never as an emergency.
Two results, printed as you would get them.
Neither of these is your app. They are the words our own checker prints, on test apps we built with the faults we see in the wild.
Your Stripe secret key is written straight into your website’s code, where anyone who visits can copy it.
Someone can use it to run up charges on your account or reach whatever it unlocks.
A key that spends your money is being handed to every visitor.
Your Supabase public key is in the page, which is where it is meant to be.
It is designed to be seen by every visitor, and on its own it unlocks nothing. What decides whether your data is safe is the rules on each table, which we check separately.
The key we found is the one that is supposed to be public.
We found a real one. Now what?
Two steps, in this order. Replace the key at whoever issued it, because it has to be treated as already copied, then move it out of the browser code onto your server. Doing only the second leaves a key in the wild that still works.
The free check tells you which key, which provider, and where in the page it is. Paying gets you the sentence to paste back into the tool you built with, written for that tool, and a re-check that says plainly whether it is gone.
The questions people ask.
- Will you show me the key you found?
- No, and neither will your report. We show you the provider, where it was and enough of it to recognise, blanked past its first characters. A report that printed the whole key would be a second copy of the problem, sitting in your inbox.
- How do you know which keys are meant to be public?
- We read what the key itself says about what it can do, rather than guessing from its name. That is the whole second example above. Getting this wrong in the alarming direction is how a scanner trains you to ignore it.
- Can you see keys that are not on my website?
- Not from your web address alone. A key committed into your project files rather than served to a browser is found by reading the code, which needs you to connect it and is part of a paid plan. The free check is honest about which of the two it looked at.