How to restrict a Firebase API key, step by step

A Firebase API key sits in your app's config, so anyone who opens your site or unpacks your app can copy it. That's expected: Firebase says "API keys for Firebase services are OK to include in code or checked-in config files." (Firebase API keys). What isn't fine is a key that can call more than your app needs. Google's docs are blunt about it: "Unrestricted API keys are insecure." (API key restrictions).

Three of our horror stories started the same way, with a public key that could also call Gemini: $82,314 in 48 hours, €54,000 in 13 hours and $67,000 in 19 hours.

Firebase restricts the keys it creates, but an older key may allow more than you think. When Firebase restricted existing keys in May 2024, each one was "restricted to the list of the Firebase-related APIs plus any of the project's currently enabled APIs." A paid API that was enabled then stayed on the key.

Open APIs & Services > Credentials in the Google Cloud console and pick your project: every API key is listed there. Firebase creates one per platform, a Browser key with the project and an iOS or Android key when you add those apps. Look for keys you or a teammate created by hand too, and for keys that came with other Google services, like Maps.

To see which key each app uses, go to the Firebase console, Project settings > General > Your apps. Web apps show it as apiKey in the config object, Android apps as current_key in google-services.json, and Apple apps as API_KEY in GoogleService-Info.plist.

This is the restriction that bounds the damage. Without it, "an API key can be used to access any API that is enabled for the project." (Firebase API keys).

In the Credentials page:

1. Click the key's name.
2. Under API restrictions, choose Restrict key.
3. Select only the APIs your app calls from the client. For a typical Firebase app that's the Firebase APIs it uses, such as Identity Toolkit for Auth, Cloud Firestore and Firebase Installations.
4. Click Save.

Go carefully with production keys. If you remove an API your app needs, its calls fail with an API_KEY_SERVICE_BLOCKED error. Firebase keeps a list of the APIs each Firebase service needs for each product: check it before removing one, and try the change on a test key first.

From the command line, list the keys to get their IDs, then set the APIs. The list you pass is the whole list: "the service names provided replace any existing services on the key."

gcloud services api-keys list --project=PROJECT_ID

gcloud services api-keys update KEY_ID \
  --api-target=service=identitytoolkit.googleapis.com \
  --api-target=service=securetoken.googleapis.com \
  --api-target=service=firestore.googleapis.com \
  --api-target=service=firebaseinstallations.googleapis.com

Application restrictions say which websites or apps may use the key. Without them, as Google puts it, "API keys without application restrictions can be used from anywhere." Each key takes one kind: "You can apply only one application restriction type at a time." Pick the one that matches the key (API key restrictions):

• Websites. For the Browser key, add your domains as HTTP referrers. To allow a whole site, Google's docs use two entries, example.com/* and *.example.com/*. Use a separate key for localhost rather than adding it to the production key.
• Android apps. Add the package name and the SHA-1 fingerprint of each signing certificate.
• iOS apps. Add the bundle ID.

Treat these as a filter, not a lock. For the Android and iOS restrictions Google warns: "Bypassing this restriction is straightforward." A referrer is just a header too, and a script outside a browser can send any value it likes. Application restrictions stop casual reuse of your key. The API restrictions from step 2 are what limit the bill.

Firebase's advice is direct: "never include the Gemini Developer API in the allowlist for a publicly accessible API key or a key used for other services." (Firebase API keys). The same goes for any billable Google Cloud API, like Maps, Vision or Translation. Give it a separate key that can call only that API, so you can restrict, rotate or delete it without touching Firebase.

If your server calls the Gemini Developer API, that key is a real secret. Firebase says it "should never be included in your code or configuration files." Keep it in your backend's secrets, never in the app.

If your app calls Gemini through Firebase AI Logic, the requests go through Firebase and there is no Gemini key in the client. Anyone with your app's config can still try to send them, so protect them with App Check and a per-day quota on the API (how to set limits).

A key that was never meant to be public, like a server key pushed to a repository, needs more than restrictions. Rotate it: on the key's page, click Rotate key. Google creates a new key with the same restrictions, you move your apps and servers to it, and then you delete the previous key (rotating an API key).

A Firebase key inside a shipped app is different. Every installed copy has it, so rotating it breaks old versions. For that key, the restrictions above are the fix.

A restricted key can still call every API on its list, as often as someone wants. Three more layers cover that: Security Rules decide who reads and writes which data, App Check rejects requests that don't come from your real app, and quotas cap how many calls an API takes per day. How to limit Firebase spending covers each one.

And when something gets through anyway, FireShield watches each API's usage every few minutes. A service with no traffic that suddenly gets thousands of requests, like Gemini in the three stories above, is flagged within minutes and can trigger an action, up to disconnecting billing.