Clave API expuesta en una aplicación: autopsia de un defecto y 600 000 dólares en METR

Un probador nos envió su proyecto porque la base de datos en línea no se conectaba. Al abrirlo vimos su clave de acceso escrita en claro en la aplicación. Cuánto cuesta en otros lugares y qué cambiamos ese mismo día.

Una clave API expuesta en una aplicación es una contraseña de servicio dejada en texto claro, legible por cualquiera que abra el archivo. El instituto de evaluación METR cuenta (Update on Security at METR, 31 de agosto de 2026) que una clave robada de una aplicación publicada sin autenticación efectiva sirvió para consumir, en tres semanas, créditos por un valor aproximado de 600 000 dólares.

Qué es una clave, en una frase

Tu aplicación suele necesitar hablar con un servicio externo: una base de datos en línea, un envío de emails o un pago. Ese servicio no conoce tu aplicación: conoce una cadena de caracteres que demuestra que la petición viene de ti. Quien posea esa cadena puede hacer lo que hace tu aplicación: leer tus clientes, escribir en su lugar y gastar en tu cuenta. Por tanto, debe vivir fuera del código, en una caja fuerte que el programa consulte cuando la necesite.

Lo que le ocurrió a un instituto de evaluación

METR se dedica a evaluar sistemas de IA. Por tanto, no se trata de una pequeña empresa distraída. En marzo de 2026, unos atacantes robaron una clave de acceso dejada en una aplicación desplegada cuya autenticación había dejado de funcionar y consumieron durante tres semanas créditos que habrían valido unos 600 000 dólares (el proveedor se los había regalado a METR, por lo que la pérdida financiera fue teórica). Un segundo episodio, a principios de mayo, afectó a un visualizador público. Dos lecciones caben en pocas palabras: una protección puede apagarse sin avisar y un consumo anormal puede durar tres semanas antes de verse.

Nuestro propio defecto, encontrado por un probador

A finales de agosto, un probador de nuestra beta nos envió su proyecto, una aplicación móvil que había construido él mismo, porque su base de datos en línea no se conectaba. La dirección de la base y su clave privada estaban fijadas en el código. Nuestra responsabilidad era doble. Primero, nunca se lo habíamos dicho: en un programa existente retomado en Maestro, la tarjeta que habla de la base en línea no podía aparecer porque dependía de una etapa por la que ese recorrido nunca pasa. Después, nada impedía que esa clave viajara en una copia de seguridad en línea. No había hecho ninguna tontería: su asistente de IA había escrito el código así, la aplicación funcionaba y ninguna pantalla le había señalado la diferencia entre una clave guardada y una pegada en un archivo que viaja.

Lo que cambiamos y lo que rechazamos hacer

Guardar la clave se propone, nunca se impone: el producto muestra dónde está, explica el riesgo y se mueve con tu acuerdo. Cuando hay una clave privada en el código, se rechaza la copia en línea si el destino es público o de origen desconocido y se avisa si es privado. Además, la tarjeta de la base en línea aparece ahora en un programa retomado, sin depender de una etapa que ese recorrido nunca alcanza. Todo se construyó y publicó el 30 de agosto de 2026 en la versión 0.1.13, y puedes leer lo que sabemos de tus datos en su página dedicada. Descartamos dos respuestas más fáciles. Mover nosotros mismos la clave sin preguntar: una herramienta que toca sola los accesos de un servicio en producción fabrica fallos que su propietario no sabe explicar. Y bloquear a todos por principio: muchos proyectos retomados tienen una buena razón para tener una clave pública en ese lugar, y una herramienta que da falsas alarmas cada vez que se abre acaba ignorada.

Por qué ocurre tan a menudo

Veracode midió, en su informe del 28 de julio de 2026, que el 44 % de las tareas de generación de código produce una vulnerabilidad, una tasa casi idéntica a la del año anterior. Un asistente que escribe rápido escribe lo que funciona, y una clave pegada en el archivo funciona. Nada en pantalla distingue una aplicación sana de una abierta: ambas arrancan, ambas muestran tus datos, y ese es precisamente el problema. Por tanto, el control debe venir de la herramienta, al escribir el código y al enviarlo.

En la práctica, esta noche

Busca en los archivos de tu proyecto las palabras key, token y secret, y mira lo que sigue: una secuencia larga de caracteres sin significado es una clave. Basta la búsqueda de texto de tu sistema; no hay código que leer. Si encuentras una en un archivo que se distribuye con la aplicación, regenera esa clave en el proveedor y guarda la nueva en los ajustes del servicio. Comprueba después lo que tu base permite mostrar sin contraseña: la prueba se hace en dos minutos. Un probador nos hizo ese favor por accidente; nadie te garantiza el mismo azar.