Guides

Google suspended my project over an API key in my app. Here’s how to avoid it

In May 2026, Google Cloud suspended the project behind Sleevr, our multiplayer trivia game. Everything on that project stopped working until it was sorted out. I’d like to say it was bad luck, but the cause was mine: a Gemini API key was compiled into every copy of the app we had shipped, with no application restrictions on it. Anyone who unpacked the APK could have pulled the key out and used it.

The project was reinstated a week later. This guide is what I learned, written for anyone shipping a mobile app that talks to a paid API.

What went wrong

A mobile app is not a safe place for a secret. When you build an Android app, everything in it, including strings, config files and constants, ends up in the APK that users download. Tools to unpack an APK and read those strings are free and take minutes to use. Obfuscation makes it slower, not impossible.

Our key was an API key for Gemini, Google’s AI API, which is billed per request. It sat in the app with no restrictions saying which app or which APIs it could be used for. From Google’s side, a key like that is a risk to the project whether or not anyone has misused it yet, and keys found in public places get abused for exactly that reason.

What I did to get reinstated

1. Audited every key on the project, not just the one that caused the problem. There were four. For each, I listed where it was used and what it needed to call.
2. Rotated them: created new keys, shipped the app changes that used them, and deleted the old ones, so the leaked key stopped working everywhere.
3. Restricted every new key to the APIs it actually calls and to our app, so a copied key would be useless elsewhere.
4. Scrubbed the keys from the repository history. Deleting a key from the current code isn’t enough while it’s still in old commits.
5. Wrote up the whole thing for the appeal: what was exposed, how, what had been changed, and how it would be prevented. A clear, honest account is what the review needs to see.

How to avoid it in your own app

The fixes are not complicated, and almost all of them take minutes. The hard part is doing them before you ship rather than after.

1. Keep paid API keys out of the app entirely

The safest key is one the app never contains. Instead of calling a paid API directly from the phone, have the app call your own backend, such as a Cloud Function, and let the backend call the API with a key kept in a secret manager. Your backend can then check who is asking, limit how often, and refuse anything unexpected. For AI APIs this also lets you change prompts and models without shipping an update.

2. Restrict every key that does ship

Some keys have to be in the app, such as the Firebase config or a Maps key. Google’s documentation is clear that the Firebase config isn’t a secret in itself, but every key should still be restricted in the Google Cloud console:

• Application restrictions: for Android, limit the key to your package name and your signing certificate’s SHA-1 fingerprint. For the web, limit it to your domains.
• API restrictions: allow only the APIs that key needs. A Maps key has no business calling Gemini.
• Remember that application restrictions on Android keys can be spoofed by a determined attacker, which is why paid APIs belong behind your backend rather than relying on restrictions alone.

3. Add App Check and budgets

Firebase App Check lets your backend and Firebase services reject requests that don’t come from your genuine app on a genuine device. Pair it with billing budgets and alerts in Google Cloud, so a sudden spike in usage emails you the same day instead of showing up at the end of the month. Quotas on individual APIs put a hard ceiling on how much a leaked key could cost.

4. Keep keys out of your repository

• Store keys in environment files or a secret manager that are excluded from version control, and add the filenames to .gitignore before you create them.
• Turn on secret scanning in your Git host. GitHub can block a push that contains a recognisable key.
• If a key is ever committed, treat it as leaked: rotate it first, then clean the history with a tool such as git filter-repo.

5. Audit before every release

Once per release, run through the list: which keys exist on the project, where each is used, what each is allowed to do, and whether any appear in the built app. Unpack your own APK and search it for “key” and “AIza”, the prefix Google API keys start with. If you can find a secret in a minute, so can anyone else.

If it happens to you

Don’t panic, and don’t appeal immediately with a one-line request. Fix the problem completely first: rotate, restrict, remove from history and check every other key on the project. Then write an appeal that explains what happened, what you changed and how you’ll prevent it. In our case that got the project back within a week. The suspension was painful, but the project is now in better shape than it was before, and every app we build starts with these rules.