API keys expuestas: los 5 lugares por donde se filtran (y cómo compartirlas bien)
Una API key es una contraseña sin usuario, sin MFA y, muchas veces, con permisos de producción. Y sin embargo circula por lugares por los que nadie mandaría la contraseña del banco: repos, chats, tickets, documentos compartidos. Este es el mapa de los cinco puntos de fuga más comunes en equipos de desarrollo reales — y el circuito para que compartir una key deje de ser un evento de riesgo.
1. El repositorio (y su historial, que no perdona)
El clásico: la key hardcodeada en el código o en un archivo de configuración que terminó commiteado. El detalle que agrava todo es el historial de git: borrar la key en un commit nuevo no la elimina — sigue accesible en los commits anteriores para cualquiera con acceso al repo, y reescribir el historial en un repo compartido es costoso y propenso a errores. Si el repo es o fue público, hay que asumer compromiso inmediato: existen actores automatizados escaneando repos públicos en busca de credenciales de forma continua, y el tiempo entre exposición y explotación se mide en minutos. La única respuesta correcta a una key commiteada es rotarla — limpiarla del código es higiene, no remediación.
2. Los chats y correos del equipo
"¿Me pasás la key de staging?" es probablemente la frase que más credenciales ha movido por Slack en la historia. Todo lo que aplica a contraseñas por chat aplica acá con un agravante: las API keys suelen tener vidas más largas que las contraseñas (nadie las rota por política de expiración) y permisos más amplios de lo necesario. Una key de producción compartida en un canal de equipo en 2024 probablemente siga siendo válida hoy, buscable por cualquiera que haya entrado a ese canal desde entonces. El historial de chat funciona en la práctica como un gestor de secretos involuntario: sin control de acceso, sin registro de quién la vio, y sin fecha de vencimiento.
3. Logs, variables de entorno y mensajes de error
Las keys también se filtran sin que nadie las comparta: un logger que imprime la request completa con el header de autorización, un stack trace que vuelca las variables de entorno, un mensaje de error que un desarrollador copia y pega entero en un ticket o en un chat para pedir ayuda. Ese último caso es el más traicionero, porque combina dos fugas: el secreto sale del sistema de logs (que al menos tiene control de acceso) y entra al canal de mensajería (que no lo trata como secreto). La regla operativa: los logs no deben registrar credenciales — y cuando pedís ayuda con un error, lo que pegás se revisa antes de enviarse.
4. Documentos compartidos y wikis internas
La página de la wiki que se llama "Accesos", el Google Doc "Credenciales del proyecto", la planilla con las keys de todos los ambientes. Nacen como solución bienintencionada al caos del chat, y crean un problema peor: un único documento cuyo control de acceso se degrada con el tiempo (se comparte "con el equipo", después "con cualquiera con el link"), que no registra quién consultó qué, y que concentra todo el botín en un solo lugar. Un documento estático es lo contrario de un gestor de secretos: en lugar de entregar cada secreto a quien lo necesita cuando lo necesita, expone todos los secretos a todos los que alguna vez necesitaron uno.
5. El intercambio con externos: proveedores, freelancers, soporte
El punto de fuga con menos control de todos: le pasás una key a un freelancer para que integre un servicio, a un proveedor para un troubleshooting, al soporte de una plataforma para reproducir un bug. El secreto sale de tu perímetro hacia el correo o el chat de una persona cuyas prácticas de seguridad no conocés ni controlás, y sobre la que no tenés offboarding: cuando el proyecto termina, la key sigue en su casilla. Para estos intercambios, el mecanismo de envío importa más que en ningún otro caso — y la rotación al finalizar el trabajo tiene que estar agendada desde el día uno, no depender de que alguien se acuerde.
El circuito correcto para compartir una key
El patrón que cierra estos cinco frentes es el mismo: los secretos viajan por un canal diseñado para secretos, y viven en sistemas diseñados para guardarlos. En la práctica: las aplicaciones consumen keys desde variables de entorno o un gestor de secretos, nunca desde el código; las personas se transmiten keys por un mecanismo de compartición segura, nunca por chat, email, tickets ni documentos; toda key que haya tocado un canal inseguro se rota, sin debatir si "alguien la habrá visto"; y los permisos de cada key se acotan a lo que su consumidor necesita, para que la que inevitablemente se filtre haga el menor daño posible. Nada de esto es exótico — lo difícil es que el canal seguro sea tan cómodo que se use siempre, incluso a las 7 de la tarde de un viernes con producción caída.
Que compartir una key deje de ser un riesgo
ShaSafSec es el canal designado para mover keys y secretos entre personas — dentro del equipo o con externos — sin dejarlos regados en chats, correos y documentos.
Ver cómo funciona →