Una API key puede tardar segundos en generarse y segundos en quedar expuesta. El problema es que puede continuar siendo válida durante semanas o meses.
Una situación bastante habitual ocurre durante la depuración de una aplicación: una solicitud falla, el desarrollador imprime los encabezados HTTP, se registra la respuesta completa de una API o se activa un modo debug.
El resultado puede ser una credencial almacenada en un archivo de log.
Y ese archivo puede terminar en un sistema de monitoreo, un repositorio, una plataforma de CI/CD o una copia de seguridad.
## Eliminar el texto no resuelve el problema
Supongamos que encontramos lo siguiente en un registro:
`Authorization: Bearer [TOKEN EXPUESTO]`
El primer impulso puede ser borrar el registro o eliminar la línea del código que produjo la exposición.
Pero hay algo más importante: si alguien tuvo acceso al token, debemos asumir que puede seguir utilizándolo.
Un secreto expuesto debe tratarse como una credencial comprometida.
## Qué hacer inmediatamente
**1. Identificar qué credencial se expuso**
Determinar si se trata de una API key, un token OAuth, una contraseña, una credencial de base de datos o una clave privada.
Identificar también qué servicios y permisos están asociados.
**2. Revocar o rotar el secreto**
Desde el proveedor correspondiente, revocar la credencial comprometida y generar una nueva.
No alcanza con reiniciar la aplicación ni con cambiar una variable de entorno. La credencial anterior puede continuar funcionando hasta que sea revocada o expire.
**3. Revisar actividad sospechosa**
Consultar los registros del proveedor para identificar solicitudes, direcciones IP, horarios y operaciones que no correspondan al comportamiento habitual.
**4. Buscar otras copias**
Revisar:
- Logs de aplicaciones.
- Registros de CI/CD.
- Herramientas de monitoreo.
- Historial de Git.
- Artefactos de compilación.
- Tickets y sistemas de soporte.
- Backups y archivos temporales.
**5. Evaluar el alcance**
Si la credencial permitía acceder a una base de datos, otros servicios o información de usuarios, hay que evaluar también esos posibles accesos.
**6. Corregir el origen**
Antes de volver a desplegar, eliminar la causa que permitió registrar el secreto.
## Cómo evitar que vuelva a suceder
La guía de logging de OWASP recomienda no registrar directamente tokens de acceso, contraseñas, cadenas de conexión y claves criptográficas.
En lugar de registrar el contenido completo de una solicitud, conviene registrar información estructurada:
- Identificador de la operación.
- Servicio involucrado.
- Código HTTP.
- Resultado de la solicitud.
- Duración.
- Identificador de correlación.
Por ejemplo, es posible registrar que una integración falló por un error de autenticación sin almacenar el token utilizado.
También conviene implementar:
- Secret scanning en los repositorios.
- Variables de entorno o gestores de secretos.
- Credenciales con permisos mínimos.
- Tokens con vencimiento cuando sea posible.
- Rotación periódica o ante sospechas de exposición.
- Acceso restringido a los registros.
## El secreto no es el archivo: es el acceso que permite
Un token puede aparecer en un log aparentemente inofensivo, pero representar acceso a servicios, datos y operaciones de negocio.
La respuesta correcta no es solamente limpiar el archivo. Es revocar la credencial, investigar el posible uso indebido y evitar que la aplicación vuelva a registrar información sensible.
La seguridad también consiste en controlar qué información dejamos detrás cuando algo falla.
**Referencias:** OWASP Logging Cheat Sheet, OWASP Secrets Management Cheat Sheet y GitHub Secret Scanning.