Credentials in source code

Una de las fugas más frecuentes en aplicaciones web son las credenciales (u otros secretos) incrustadas en el código que se entrega al cliente: ficheros JavaScript, comentarios HTML, hojas de estilo, ficheros de configuración accesibles (.env, config.js, settings.py) o repositorios .git expuestos. Todo lo que el navegador descarga es visible para cualquiera; "ofuscar" o "esconder" un secreto en el frontend no lo protege.

El primer reflejo ante cualquier web es mirar el fuente:

curl -s http://<host>/ | grep -iE 'pass|user|token|key|secret|api'
# y revisar cada .js enlazado
curl -s http://<host>/static/app.js
# rastrear y peinar TODOS los .js del sitio
katana -u http://<host>/ -jc | grep -iE '\.js' | while read u; do curl -s "$u"; done | grep -iE 'pass|token|api|secret'
# extraer endpoints y secretos de un .js
python3 linkfinder.py -i http://<host>/static/app.js -o cli
python3 SecretFinder.py -i http://<host>/static/app.js -o cli
# repositorio .git expuesto por web
git-dumper http://<host>/.git/ ./loot

Los puntos calientes habituales:

• Ficheros JavaScript. Lógica de login, llamadas a la API con claves, o credenciales "de prueba"/"de soporte" que alguien dejó para depurar (el caso de esta máquina: una URL http://usuario:contraseña@host/ruta dentro de un .js).
• Comentarios HTML/JS. <!-- TODO: quitar admin/admin antes de producción -->.
• Endpoints y parámetros ocultos referenciados en el JS pero no enlazados en la interfaz.
• Repositorio .git/ accesible, que permite reconstruir el código y su historial (donde a menudo vive un secreto que se "borró" en un commit posterior).

Una vez encontradas, las credenciales se prueban en todos los servicios (el formulario de login, Basic Auth, SSH, paneles internos): es habitual que se reutilicen, enlazando con la reutilización de credenciales.

Cómo detectarlo. El punto fuerte de este vector para el defensor es que es prevenible por escaneo: la detección de verdad es proactiva, correr secret scanners (gitleaks, trufflehog, git-secrets) sobre el repositorio y en un hook de pre-commit / CI encuentra la credencial antes de que se publique. Del lado del servidor en vivo, el acceso a ficheros que no deberían servirse (.env, .git/config, config.js) deja peticiones GET /.git/... o GET /.env en el log de acceso, una firma clásica de reconocimiento que un WAF marca. Y como el pago del vector es reutilizar la credencial encontrada, la señal posterior es un login válido de esa cuenta (ver reutilización de credenciales).

Defensa. Nunca poner secretos en código que llegue al cliente; gestionarlos en el servidor (y en gestores de secretos), no en el frontend. Bloquear el acceso a .git/ y a ficheros de configuración, y revisar el historial del repositorio antes de publicar.