Is it safe to make your Firebase API key public?

Yes. Firebase says "API keys for Firebase services are OK to include in code or checked-in config files." (Firebase API keys). Your web config, google-services.json and GoogleService-Info.plist all carry the key, and every user of your app has a copy.

But public is not the same as harmless. The key is safe when two things are true: it can only call the APIs your app needs, and your data is protected by Security Rules and App Check. Miss either one and the key becomes the way into your bill.

Most API keys work like passwords. Firebase keys don't: they say which project a request is for, so Google can apply quota and billing. Firebase explains that they are "API keys for Firebase services are not used to control access to backend resources". In its own words: "None of the Firebase-related APIs use an API key as authorization for calling the API."

Who may read or write what is decided by Firebase Security Rules, and which apps may call your backend by App Check. That's why hiding the key buys nothing, and why Firebase warns: "Don't rely only on restricting and/or obscuring your API keys." Anything in your frontend, environment variables included, ends up in the bundle your users download.

• Read or change your data. Not if your Security Rules check who's asking. The key doesn't get past the rules.
• Sign in as one of your users. Not without that user's credentials.
• Call APIs the key isn't allowed to call. With API restrictions in place, every other API rejects it.

• Call any API the key allows, on your bill. An unrestricted key works with every API enabled in the project. If Gemini, Maps or another paid API is enabled, a stranger can use it and you pay. That's how an $82,314 Gemini bill happened.
• Hammer your sign-in endpoints. Firebase notes that someone with your key could "use your API key to access Firebase's authentication endpoints and make authentication requests against your project." For example, to try passwords. It suggests lowering the quota of the Identity Toolkit API to match your normal traffic.
• Use your backend from their own code. With your config, a script can read and write whatever your rules allow, and run up reads and writes while it does. App Check is what tells your app apart from that script.

• Restrict its APIs. Allow only the APIs your app calls. Step by step: how to restrict a Firebase API key.
• Never put a non-Firebase key in the client. A Gemini Developer API key, a Maps server key or a service account file is a real secret. Firebase says the Gemini key "should never be included in your code or configuration files."
• Close your Security Rules. No allow read, write: if true outside a test project.
• Turn on App Check. It's Firebase's tool for "preventing unauthorized clients from accessing your backend resources", though Firebase is honest that it "prevents some, but not all, abuse vectors".
• Cap the volume. A per-day quota on paid APIs and a budget that triggers an action, not just an email, bound what a missed gap can cost (how to limit Firebase spending).