Guía
Secretos en el historial de Git: por qué borrar una clave no basta
4 minutos de lectura · Publicado
Por qué eliminar una clave del código no la borra del historial
Cuando borras una API key de un archivo y haces commit, git no elimina la versión anterior: solo añade un nuevo commit encima. Cualquier persona con acceso al repositorio puede usar `git log` o `git show` para volver a esa versión antigua y leer la clave tal cual estaba escrita, incluso años después.
Esto también aplica a repositorios que después se hacen privados o públicos, a forks ya existentes y a espejos que algún colaborador haya clonado antes de que se corrigiera el archivo. Si el repositorio pasó por GitHub, GitLab u otro proveedor, es posible que sistemas de caché o indexación externos hayan guardado una copia de esa versión antigua.
Los pasos correctos: rotar la clave y reescribir el historial
El primer paso no es técnico: es rotar la clave en el proveedor correspondiente (Stripe, AWS, SendGrid, etc.) para que la versión filtrada deje de ser válida. Reescribir el historial sin invalidar la clave deja el problema intacto, porque cualquier copia local que ya exista seguirá teniendo la clave activa.
Después, se puede usar `git filter-repo` o BFG Repo-Cleaner para eliminar el archivo o la cadena de todos los commits, y forzar un push con historial reescrito. Es necesario avisar a cualquier colaborador para que vuelva a clonar el repositorio, porque sus copias locales antiguas seguirán conteniendo los commits originales con la clave.
Qué revisa Audixa en el código fuente
Audixa revisa el código fuente que se entrega para el análisis y busca patrones de secretos: claves de API, tokens de acceso, cadenas de conexión a bases de datos y credenciales similares escritas directamente en archivos de configuración o código. El informe indica el archivo y la línea donde aparece cada coincidencia para que puedas revisarla.
Esta revisión se centra en el estado actual de los archivos entregados, no en ejecutar el proyecto ni en recorrer todo el historial de commits de git. Si sospechas que una clave estuvo expuesta en versiones anteriores, conviene hacer una búsqueda separada en el historial con herramientas como `git log -p` o escáneres dedicados a ese propósito.
Buenas prácticas para evitar que esto vuelva a pasar
Una forma de reducir este riesgo es no guardar secretos en archivos versionados desde el principio: usar variables de entorno cargadas fuera del repositorio, o un gestor de secretos dedicado. Un hook de pre-commit que bloquee patrones conocidos de claves también ayuda a detener el problema antes de que llegue al historial.
Revisar el proyecto antes de cada lanzamiento, y no solo una vez, permite detectar secretos añadidos por error en cambios recientes antes de que se acumulen en más commits. La página /resources/security-checklist-before-you-launch recoge otros puntos a verificar antes de publicar una aplicación.
Secretos de proveedores de pago: un caso frecuente
Un caso frecuente en proyectos con pagos es guardar la clave secreta de Stripe u otro proveedor directamente en el código del frontend, donde queda visible para cualquier visitante del sitio, además de en el historial de git. Ese tipo de error suele coexistir con otros, como un endpoint de webhook que no valida la firma de la petición.
Audixa puede señalar cuándo una clave de este tipo aparece en el código entregado y cuándo un webhook de pagos no comprueba la firma antes de procesar el evento, dos errores que suelen aparecer juntos en integraciones hechas rápido. Corregir ambos reduce el riesgo de que alguien falsifique eventos de pago o use la clave filtrada fuera del contexto previsto.
Sigue por aquí
Que las comprobaciones repetibles se ejecuten por ti
Un proyecto y un análisis al mes son gratis. Ves cuántos hallazgos hay y qué tan graves son; los títulos y la evidencia se desbloquean en un plan de pago.