TL;DR
- Generar contenido con la API de Gemini usando API keys mal configuradas está a la orden del día. Sigue leyendo antes de que te toque a ti.
- Lanzamos una herramienta de escaneo open source y gratuita para detectar API keys problemáticas. Échale un vistazo aquí: https://github.com/doitintl/gcp-apikey-check
Qué está pasando
En DoiT vemos de todo cuando se trata de la nube. Últimamente no paran de llegar reportes de la comunidad sobre sorpresas desagradables en la facturación de Gemini. El usuario puede estar usando Gemini en sus aplicaciones o no, pero un día amanece con una factura enorme por generación de contenido —muchas veces de imagen o video— que dispara los costos más rápido de lo que tardan en llegarte las alertas de facturación. Si usas API keys de Google en cualquier parte, sigue leyendo: tus keys podrían estar en riesgo.
Cómo ocurre
Google Cloud, como todos los proveedores de nube, funciona bajo un modelo de responsabilidad compartida: Google se encarga de la infraestructura subyacente y los usuarios son responsables de proteger su uso de esa infraestructura. Google utiliza un único formato de API key (AIza...) para dos propósitos muy distintos: identificadores públicos de proyecto y credenciales sensibles de autenticación.
Los problemas con las API keys de Google Maps y Firebase llevan tiempo siendo un dolor de cabeza, porque al generarlas la opción por defecto era no aplicar ninguna restricción a la API: quedaba en manos del desarrollador acotar las APIs y restringirlas a sitios web, direcciones IP o SDKs específicos, y eso no siempre se hacía. En el caso de Google Maps y Firebase, estas keys suelen ir en el código del cliente del frontend, así que no son particularmente privadas y funcionan más bien como identificadores de facturación.
Los problemas empezaron cuando se habilitó la API de Gemini en el mismo proyecto que tenía una API key de Maps o Firebase sin restricciones. Una vez que los actores maliciosos encontraron esas keys, no tardaron en aprender a explotarlas.
Cuando se habilita la API de Gemini en un proyecto de Google Cloud, todas las API keys existentes que no estén acotadas a APIs específicas en ese proyecto pueden obtener acceso silencioso a los endpoints de Gemini. Sin advertencia. Sin correo. Sin confirmación. Esa key de Maps que incrustaste en tu sitio hace años puede ser hoy una credencial activa de Gemini, a la vista de cualquiera en el código fuente de tu página.
Otro vector de fuga es subir por accidente API keys o claves estáticas de Service Account a repos públicos de GitHub. Antes, los actores maliciosos las detectaban rápido y las usaban para montar minería de cripto; sin embargo, Google ha mejorado bastante en la detección de este tipo de fraude.
Qué hace un atacante con eso
El ataque es trivial. Un actor malicioso revisa el código fuente de tu página, copia la key AIza... y llama a la API de generación de imágenes de Gemini. Eso es todo. Sin acceso a tu infraestructura, sin credenciales que robar, sin exploits sofisticados. Solo tu key y una petición HTTP, repetida muchas veces en rápida sucesión, toda facturada a tu cuenta.
¿Estás expuesto?
¿Sabrías responder estas preguntas?
- ¿Están habilitadas las APIs Generative Language o Gemini Agent Platform (antes Vertex AI) en alguno de tus proyectos de GCP?
- ¿Hay API keys sin restricción de API o sin restricción de aplicación?
- ¿Hay keys de Maps o Firebase compartidas con APIs de IA?
- ¿Tienes claves de Service Account antiguas, sin uso o con roles de owner o editor?
Si tienes más de un puñado de proyectos, revisar esto manualmente en toda tu organización no es viable.
Escanea tu organización en minutos
En DoiT trabajamos con clientes de Google Cloud todos los días. Creamos gcp-apikey-check para darle a toda la comunidad la misma visibilidad que tienen nuestros clientes: gratis y open source.
git clone https://github.com/doitintl/gcp-apikey-checkcd gcp-apikey-checkuv sync
# Escanea una organización completauv run gcpkeyscan.py --org-id YOUR_ORG_ID
# O escanea un solo proyectouv run gcpkeyscan.py --project-id YOUR_PROJECT_IDLa herramienta revisa las API keys en busca de las configuraciones erróneas que provocan estos picos de facturación: keys sin restricciones, APIs de Maps e IA en la misma key, keys de Firebase sin restricciones de aplicación y reglas de referrer demasiado amplias con comodines. También detecta claves de Service Account antiguas, sin uso o con permisos excesivos, y revisa si las políticas de tu organización siquiera permiten la creación de claves SA. Los hallazgos se etiquetan por severidad (CRITICAL / HIGH / MED) y se exportan a JSON y CSV para que puedas actuar de inmediato.
Arréglalo y replantéate si de verdad necesitas keys
Lo más importante que hay que entender: la mejor API key es la que no existe.
Las propias buenas prácticas de Google son claras: evita las API keys y las claves de Service Account siempre que sea posible. Las API keys no tienen identidad, no caducan por defecto y no dejan un rastro de auditoría detallado. Para servicios de backend y workloads en GCP, casi siempre hay una mejor alternativa:
- Usa Workload Identity Federation en lugar de claves de Service Account para la autenticación servidor a servidor.
- Usa Application Default Credentials con roles IAM para workloads que corren en GCP.
- Llama a Gemini desde el servidor con un IAM adecuado; nunca expongas una key en el código del cliente.
Si no te queda otra que usar API keys (para embeds de Maps, SDKs cliente de Firebase u otros casos legítimos del lado del cliente), restríngelas como corresponde:
- Limita cada key a las APIs específicas que necesita.
- Agrega restricciones de aplicación: HTTP referrer para web, bundle ID para móvil, rango de IPs para servidor.
- Nunca pongas keys de Maps o Firebase en la misma key que Gemini u otra API de IA.
- Desactiva las APIs que no estés usando activamente.
- Configura alertas de facturación para que un pico no pase desapercibido durante días.
Para las claves de Service Account que todavía no puedas eliminar: rota cualquiera que tenga más de 90 días, quita los roles de owner y editor, y borra las que no se hayan usado recientemente.
La buena noticia es que Google ha vuelto más restrictivos los valores por defecto al crear nuevas API keys: ya no se puede crear una key sin restricciones. Google AI Studio también crea API keys nuevas restringidas únicamente a la API de Gemini. Esto no resuelve todos los problemas, pero tener defaults más sensatos ayuda.
No esperes a que llegue la factura
Google avanza hacia defaults más estrictos, pero aún no está claro qué tan pronto llegarán ni si esos cambios protegerán las keys ya desplegadas en tus proyectos. Los desarrolladores que cuentan historias de cargos sorpresa no sabían que estaban expuestos hasta que ya era tarde.
Corre el escaneo hoy. Descubre qué tienes. Corrige primero lo más grave y, después, trabaja para eliminar las keys por completo donde sea posible.