I was looking through a friend's project a few months back, the kind of app someone puts together in a weekend with an AI coding tool and then quietly worries about for the rest of the year. He opened his browser's dev tools to show me something unrelated, and there it was, sitting right in the page source: an API key, in plain text, for anyone to read. His face went a little pale. Mine did too, for about ten seconds, until I actually looked at what that key was for.
Seeing a key in your front-end code is not automatically a five-alarm fire. It might be exactly where it's supposed to be. The problem is that almost nobody knows how to tell the difference between a key that's fine to expose and one that isn't, so everybody either panics over nothing or ignores something that actually matters. There's a simple way to check, and it only takes about two minutes.
Two kinds of keys, one word doing all the work
Every key gets called an "API key," and the word does a lot of hiding. In practice there are two very different things wearing the same name. One kind is built to be public. It sits in your HTML, your JavaScript bundle, your compiled app, wherever a browser or a phone can read it, because whatever it talks to was designed assuming a stranger would eventually see it. The other kind is built to be secret. It's supposed to live on a server, get used server-side, and never touch a device you don't control. Same shape, usually a plain string of letters and numbers, completely different job.
The naming hint, and why it's only a hint
A lot of services help you out by naming the two differently: a "publishable" key next to a "secret" one, a "public" key next to a "private" one, sometimes with the distinction baked right into the string itself as a short prefix. That's a genuinely useful first clue, and worth learning for whatever platform you're building on. But don't stop there. Plenty of tools don't label anything at all, and a key that's meant to be public can still hand out more than it should if nobody locked down what it's allowed to touch on the other end. The name on the key tells you the intent. It doesn't tell you what the key can actually do.
The test: what can this key actually do
Here's the part you can run yourself, right now, with nothing but a browser.
- Open your app, then open dev tools (right click, "Inspect," or F12) and go to the Network tab.
- Reload the page and click through a few normal actions: log in, load a list, submit something small.
- Watch the requests go by and look for anything with "key," "token," or "Authorization" attached to it. Click one and look at the value.
- Open a private or incognito window, logged out of everything, and send a basic request to that same address using only that key (a simple GET request through a tool like curl, or even a URL with the key pasted in, works for this).
- Ask one question of what comes back: can I read or write anything I shouldn't be able to, with no session and no login, nothing but the bare key?
If the answer is no, because whatever is behind that key checks who's actually asking before it hands over anything real, you're probably looking at a normal public key doing its normal job. If the answer is yes, if that bare key alone can pull someone else's data, write to a database, or send something on your behalf, you've found a secret sitting somewhere a secret doesn't belong.
What last year's stories actually taught
This is the exact shape of bug that made the rounds all through last year, across more than one popular AI app builder. It was rarely the key itself that got someone in trouble. It was a key handing out real access because nobody had set up rules on the other side to check who was asking. In one case, researchers found the same gap sitting open in more than a hundred and fifty live apps at once, all built on the same platform, because the flaw was baked into the platform's default setup, not caused by anything any one developer did wrong.
That number lines up with what you find just poking around apps for fun. The code usually works. Whether it checks its own permissions is a separate question, and it's the one that decides whether an exposed key is a shrug or a problem.
Before you ship
If you run the test above and you're not sure what you're looking at, or the key clearly does more than it should, don't just rotate it and move on. Rotating a key fixes that one key. It doesn't fix whatever let it do too much in the first place, so go find that part and fix it too before you consider the job done.