Claves de Google Cloud expuestas: de simples identificadores a credenciales que activan IA generativa y podrían costarte miles

Hace unos meses cambió silenciosamente una suposición que muchos desarrolladores daban por sentada: las claves de API de Google Cloud que se colocaban en páginas web públicas para cargas como mapas o vídeos dejaron de ser simplemente identificadores inofensivos. Con la llegada de Gemini y la posibilidad de habilitar la API de modelos generativos en proyectos, esas claves empezaron a funcionar también como credenciales que pueden autorizar llamadas al asistente de IA y, en algunos casos, a datos privados asociados.

El problema lo puso en evidencia un equipo de investigación que rastreó el panorama público del código web: al analizar una instantánea representativa del índice de internet, encontraron miles de claves de Google visibles en código cliente. Esa investigación, publicada por Truffle Security, revela que alrededor de 2.800 claves vivas estaban expuestas en páginas accesibles públicamente y que, en varios casos, esas mismas claves podían invocar la API de Gemini. Entre los hallazgos hay claves usadas por instituciones financieras, empresas de seguridad y firmas de contratación, y hasta una clave integrada en la web pública de un producto de Google.

Tradicionalmente, muchas claves de Google Cloud se trataron como algo no crítico: servían para identificar la facturación o habilitar servicios sencillos en el navegador —como cargar Google Maps, insertar vídeos de YouTube, o usar Firebase en una app web— y se confiaba en que los límites de referrer o de uso bastaban. Sin embargo, cuando un proyecto activa la API de lenguaje generativo (Generative Language API), esa misma clave puede adquirir privilegios adicionales y permitir a quien la posea ejecutar modelos y acceder a funcionalidades que antes no estaban disponibles desde código cliente.

La consecuencia práctica es doble. Por un lado, existe el riesgo de exposición de información: ataques dirigidos usando la clave pueden intentar leer o manipular datos a los que tenga acceso el servicio. Por otro, y quizá más inmediato para muchas organizaciones, está el coste económico: las llamadas a modelos grandes no son gratis, y un agresor que abuse de una clave expuesta puede provocar facturas importantes. Como señalan los investigadores, saturar peticiones contra un modelo con contexto amplio puede traducirse en miles de dólares diarios cargados a la cuenta víctima.

Los hallazgos se apoyan en análisis sobre un conjunto masivo de páginas web y no son un caso anecdótico. Truffle Security documentó que varias claves habían estado embebidas en código público durante años y, tras probar llamadas a endpoints de Gemini para enumerar modelos, confirmaron que esas claves funcionaban para el nuevo servicio. La investigación fue notificada a Google y, tras un intercambio de comunicaciones, la compañía clasificó el problema como una forma de escalada de privilegios para un servicio específico.

La respuesta de Google, según declaraciones recogidas por medios especializados, incluyó medidas técnicas y recomendaciones operativas: bloquear el acceso de claves filtradas a Gemini, emitir notificaciones proactivas cuando se detecten fugas y ajustar el alcance por defecto de nuevas claves generadas desde AI Studio para que sean específicas de Gemini. Estas acciones ayudan, pero no son sustitutas de una higiene de seguridad apropiada en los proyectos.

Para desarrolladores y responsables de producto esto supone una obligación inmediata de auditoría. Es imprescindible revisar los proyectos y comprobar si la API generativa está habilitada; si así fuera, hay que revisar todas las claves públicas o embebidas en código y rotarlas sin demora. Además, conviene revisar permisos, aplicar restricciones estrictas de referrer o de IP cuando sea posible, y configurar límites de cuota y alertas de facturación para detectar consumos anómalos.

Hay herramientas que facilitan la detección de secretos expuestos en repositorios y código público; los propios investigadores recomiendan TruffleHog como punto de partida para escanear y encontrar claves que estén accesibles desde el frontend o en historiales de commits. También merece la pena revisar las guías oficiales de Google sobre prácticas de clave API y autenticación, que describen cómo mitigar riesgos y configurar controles más finos: documentación de Google Cloud sobre claves API.

Más allá de la limpieza puntual, esto plantea una reflexión más amplia sobre cómo la evolución de plataformas y servicios puede cambiar la sensibilidad de ciertos artefactos técnicos. Algo que ayer se consideraba relativamente inocuo —una clave pública usada para cargar un mapa— puede convertirse hoy en un vector crítico si la misma credencial empieza a autorizar acceso a IA generativa o a funciones que no se habían anticipado. Por eso es clave revisar supuestos, aplicar el principio de menor privilegio y profesionalizar la gestión de secretos.

En el terreno operativo, implementar autenticación desde el servidor para llamadas sensibles, usar cuentas de servicio con permisos mínimos, y separar las claves de uso público de las que tienen capacidad de invocar APIs potentes son medidas que reducen la exposición. También es recomendable mantener procesos automáticos que monitoricen la aparición de secretos en commits o en el frontend y que obliguen la rotación de credenciales comprometidas. La documentación de seguridad y las mejores prácticas cambian con la tecnología; la responsabilidad de los equipos es mantenerlas al día.

El incidente subraya además la importancia de la colaboración entre investigadores y proveedores. La detección y notificación responsable por parte de terceros ayudó a que se adoptaran bloqueos y controles en un servicio que cambia rápidamente. Para quien quiera profundizar en la investigación original, el informe y la entrada del equipo que detectó la exposición están disponibles en el blog de Truffle Security, que detalla metodología y ejemplos concretos: análisis de Truffle Security. También puede consultarse la cobertura periodística que recoge las declaraciones de Google y el alcance del hallazgo en medios como BleepingComputer.

Si gestionas proyectos con servicios en la nube, no lo dejes para después: revisa si tu código cliente contiene claves visibles, identifica qué permisos tienen esas credenciales y actúa con rotación y restricciones. La seguridad no es estática; una clave expuesta hoy puede volverse peligrosa mañana por cambios en las plataformas, y la diferencia entre un incidente menor y una fuga grave a menudo está en la rapidez con la que se detecta y corrige la exposición.