Cómo restringir una API key de Firebase, paso a paso

Una API key de Firebase está en la configuración de tu app, así que cualquiera que abra tu web o descomprima tu app puede copiarla. Es lo esperado: Firebase dice "API keys for Firebase services are OK to include in code or checked-in config files." (las API keys de los servicios de Firebase se pueden incluir en el código o en archivos de configuración versionados) (API keys de Firebase). Lo que no está bien es una clave que puede llamar a más cosas de las que tu app necesita. La documentación de Google lo dice sin rodeos: "Unrestricted API keys are insecure." (las API keys sin restricciones son inseguras) (restricciones de API keys).

Tres de nuestras historias de terror empezaron igual, con una clave pública que además podía llamar a Gemini: 82.314 $ en 48 horas, 54.000 € en 13 horas y 67.000 $ en 19 horas.

Firebase restringe las claves que crea, pero una clave antigua puede permitir más de lo que crees. Cuando Firebase restringió las claves existentes en mayo de 2024, cada una quedó "restricted to the list of the Firebase-related APIs plus any of the project's currently enabled APIs." (restringida a la lista de APIs relacionadas con Firebase más cualquier API que el proyecto tuviera activada en ese momento). Una API de pago activada entonces se quedó en la clave.

Abre APIs y servicios > Credenciales en la consola de Google Cloud y elige tu proyecto: ahí aparecen todas las API keys. Firebase crea una por plataforma, una Browser key con el proyecto y una clave de iOS o Android cuando añades esas apps. Busca también las claves que tú o alguien del equipo creasteis a mano, y las que llegaron con otros servicios de Google, como Maps.

Para ver qué clave usa cada app, ve a la consola de Firebase, Configuración del proyecto > General > Tus apps. Las apps web la muestran como apiKey en el objeto de configuración, las de Android como current_key en google-services.json y las de Apple como API_KEY en GoogleService-Info.plist.

Esta es la restricción que acota el daño. Sin ella, "an API key can be used to access any API that is enabled for the project." (una API key puede usarse para acceder a cualquier API activada en el proyecto) (API keys de Firebase).

En la página de Credenciales:

1. Haz clic en el nombre de la clave.
2. En Restricciones de API, elige Restringir clave.
3. Selecciona solo las APIs que tu app llama desde el cliente. En una app de Firebase típica son las APIs de Firebase que usa, como Identity Toolkit para Auth, Cloud Firestore y Firebase Installations.
4. Haz clic en Guardar.

Ve con cuidado con las claves de producción. Si quitas una API que tu app necesita, sus llamadas fallan con un error API_KEY_SERVICE_BLOCKED. Firebase mantiene una lista de las APIs que necesita cada servicio de Firebase: revísala antes de quitar una, y prueba el cambio primero en una clave de pruebas.

Desde la línea de comandos, lista las claves para obtener sus IDs y luego fija las APIs. La lista que pasas es la lista completa: "the service names provided replace any existing services on the key." (los nombres de servicio que indiques sustituyen a los que ya tenga la clave)

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

Las restricciones de aplicación dicen qué webs o apps pueden usar la clave. Sin ellas, como dice Google, "API keys without application restrictions can be used from anywhere." (las API keys sin restricciones de aplicación se pueden usar desde cualquier sitio). Cada clave admite un solo tipo: "You can apply only one application restriction type at a time." (solo puedes aplicar un tipo de restricción de aplicación a la vez). Elige el que corresponde a la clave (restricciones de API keys):

• Webs. Para la Browser key, añade tus dominios como referentes HTTP. Para permitir un sitio entero, la documentación de Google usa dos entradas, example.com/* y *.example.com/*. Usa una clave aparte para localhost en vez de añadirlo a la clave de producción.
• Apps de Android. Añade el nombre del paquete y la huella SHA-1 de cada certificado de firma.
• Apps de iOS. Añade el bundle ID.

Tómalas como un filtro, no como un candado. Sobre las restricciones de Android e iOS, Google avisa: "Bypassing this restriction is straightforward." (saltarse esta restricción es sencillo). El referente también es solo una cabecera, y un script fuera del navegador puede enviar el valor que quiera. Las restricciones de aplicación frenan la reutilización casual de tu clave. Las restricciones de API del paso 2 son las que limitan la factura.

El consejo de Firebase es directo: "never include the Gemini Developer API in the allowlist for a publicly accessible API key or a key used for other services." (nunca incluyas la Gemini Developer API en la lista de una API key pública o de una clave que se use para otros servicios) (API keys de Firebase). Lo mismo vale para cualquier API de Google Cloud que se cobre, como Maps, Vision o Translation. Dale una clave aparte que solo pueda llamar a esa API, para poder restringirla, rotarla o borrarla sin tocar Firebase.

Si tu servidor llama a la Gemini Developer API, esa clave es un secreto de verdad. Firebase dice que "should never be included in your code or configuration files." (nunca debe incluirse en tu código ni en tus archivos de configuración). Guárdala en los secretos de tu backend, nunca en la app.

Si tu app llama a Gemini con Firebase AI Logic, las peticiones pasan por Firebase y no hay ninguna clave de Gemini en el cliente. Aun así, cualquiera con la configuración de tu app puede intentar enviarlas, así que protégelas con App Check y una cuota diaria en la API (cómo poner límites).

Una clave que nunca debió ser pública, como una clave de servidor subida a un repositorio, necesita algo más que restricciones. Rótala: en la página de la clave, haz clic en Rotar clave. Google crea una clave nueva con las mismas restricciones, pasas tus apps y servidores a ella y después borras la anterior (rotar una API key).

Una clave de Firebase dentro de una app publicada es distinta. Cada copia instalada la lleva, así que rotarla rompe las versiones antiguas. Para esa clave, la solución son las restricciones de arriba.

Una clave restringida puede seguir llamando a todas las APIs de su lista, tantas veces como alguien quiera. Hay tres capas más para eso: las Security Rules deciden quién lee y escribe qué datos, App Check rechaza las peticiones que no vienen de tu app real y las cuotas limitan cuántas llamadas acepta una API al día. Cómo limitar el gasto en Firebase explica cada una.

Y si algo se cuela igualmente, FireShield vigila el uso de cada API cada pocos minutos. Un servicio sin tráfico que de repente recibe miles de peticiones, como Gemini en las tres historias de arriba, se detecta en minutos y puede disparar una acción, hasta desconectar la facturación.