Exposed API keys: how to check yours are not

An exposed API key is a password left in plain view: anyone can use it while pretending to be your app, often at your expense. To check, you look in three places: the code sent to the browser, the code repository, and error messages. If a key has leaked, you replace it, you do not just hide it.

What is a key?

When your app uses an outside service (payment, email, AI, maps), that service must know it really is you asking. You are therefore given an API key: a long string of characters that works like an access card. To understand what an API is, see what an API is.

Think of an office badge. It opens doors, and it is sometimes tied to your account: everything it does goes on your bill. If someone finds it in the street, they do not wonder who it belongs to.

How a key becomes visible

• In the code sent to the browser. Everything the browser receives can be read by any visitor in a few clicks. A key placed in that part of the code is not secret, even if it is "hard to find".
• In the code repository. If the project is published on a code-sharing site, a key written into a file stays there. Even if deleted later, it remains in the version history.
• In a screenshot, a message or a tutorial shared in good faith.
• In an error message that displays too many details.

Code-generation tools may write a key straight into a file, because it is the shortest path to making things work.

Not all keys are equal

Some keys are meant to be public: they only identify your app, and their power is limited by rules set on the other side. Others, called secret keys, grant full rights and must never leave the server. Each service's documentation says which is which.

Even a public key is only safe if those rules exist. That is exactly the case for a database: see database access rules.

How to check yours

1. List your services: payment, email, AI, storage, maps, analytics. For each, note where its key lives.
2. Look at the browser-side code. With your browser's developer tools, or with the help of a technical person, search the received files for your services' names or the start of your keys.
3. Check the code repository, history included, if it is public or shared with third parties.
4. Look at each service's dashboard. Most show when a key was last used, and some send an alert on unusual usage.

If a key has leaked

1. Revoke it and generate a new one from the service's dashboard. Only replacement makes the old one useless.
2. Review recent activity on the service for unusual use (bills, sends, access).
3. Put the new key on the server, in environment variables, never in the code.
4. Look for other keys in the same place: they probably followed the same path.

Good habits

• secret keys live on the server, in environment variables;
• one key per environment (test and production), so a leak of one does not open the other;
• limited rights: a key that can only read cannot delete everything;
• a spending cap, when the service offers one.

This is also one of the points in the launch checklist.

Remember

A visible key is a compromised key: replace it, keep it server-side, and limit its rights. Hiding is never enough.

And for your product?

An audit looks, among other things, at where your keys are and what each one allows. If you have a doubt about your app, let us talk about it in a 30-minute call.