É seguro deixar sua API key do Firebase pública?

Sim. O Firebase diz "API keys for Firebase services are OK to include in code or checked-in config files." (as API keys dos serviços do Firebase podem ser incluídas no código ou em arquivos de configuração versionados) (API keys do Firebase). Sua configuração web, o google-services.json e o GoogleService-Info.plist levam a chave, e cada usuário do seu app tem uma cópia.

Mas pública não quer dizer inofensiva. A chave é segura quando duas coisas são verdade: ela só pode chamar as APIs de que seu app precisa, e seus dados estão protegidos por Security Rules e App Check. Se faltar uma das duas, a chave vira a porta de entrada para a sua fatura.

A maioria das API keys funciona como senha. As do Firebase não: elas dizem a qual projeto uma requisição pertence, para o Google aplicar cotas e faturamento. O Firebase explica que "API keys for Firebase services are not used to control access to backend resources" (as API keys dos serviços do Firebase não são usadas para controlar o acesso aos recursos do backend). Nas palavras dele: "None of the Firebase-related APIs use an API key as authorization for calling the API." (nenhuma das APIs relacionadas ao Firebase usa uma API key como autorização para chamar a API).

Quem pode ler ou escrever o quê é decidido pelas Security Rules do Firebase, e quais apps podem chamar seu backend, pelo App Check. Por isso esconder a chave não adianta nada, e por isso o Firebase avisa: "Don't rely only on restricting and/or obscuring your API keys." (não confie apenas em restringir ou ocultar suas API keys). Tudo o que está no seu frontend, variáveis de ambiente incluídas, acaba no código que seus usuários baixam.

• Ler ou alterar seus dados. Não, se suas Security Rules verificarem quem está pedindo. A chave não passa por cima das regras.
• Entrar como um dos seus usuários. Não, sem as credenciais desse usuário.
• Chamar APIs que a chave não tem permissão para chamar. Com restrições de API, qualquer outra API a rejeita.

• Chamar qualquer API que a chave permita, na sua conta. Uma chave sem restrição funciona com todas as APIs ativadas no projeto. Se o Gemini, o Maps ou outra API paga estiver ativada, um estranho pode usá-la e você paga. Foi assim que aconteceu uma fatura de US$ 82.314 do Gemini.
• Martelar seus endpoints de login. O Firebase alerta que alguém com sua chave poderia "use your API key to access Firebase's authentication endpoints and make authentication requests against your project." (usar sua API key para acessar os endpoints de autenticação do Firebase e fazer requisições de autenticação contra o seu projeto). Por exemplo, para testar senhas. Ele recomenda baixar a cota da API Identity Toolkit para o seu tráfego normal.
• Usar seu backend a partir do próprio código. Com sua configuração, um script pode ler e escrever tudo o que suas regras permitem, e gerar leituras e gravações enquanto isso. O App Check é o que diferencia seu app desse script.

• Restrinja as APIs dela. Permita só as APIs que seu app chama. Passo a passo: como restringir uma API key do Firebase.
• Nunca coloque no cliente uma chave que não seja do Firebase. Uma chave da Gemini Developer API, uma chave de servidor do Maps ou um arquivo de conta de serviço são segredos de verdade. O Firebase diz que a chave do Gemini "should never be included in your code or configuration files." (nunca deve ser incluída no seu código nem nos seus arquivos de configuração).
• Feche suas Security Rules. Nada de allow read, write: if true fora de um projeto de testes.
• Ative o App Check. É a ferramenta do Firebase para "preventing unauthorized clients from accessing your backend resources" (impedir que clientes não autorizados acessem os recursos do seu backend), embora o Firebase admita que ele "prevents some, but not all, abuse vectors" (evita alguns vetores de abuso, mas não todos).
• Limite o volume. Uma cota diária nas APIs pagas e um orçamento que dispare uma ação, não só um email, limitam quanto pode custar uma brecha que escapou (como limitar os gastos no Firebase).