Brecha oculta de las SPA credenciales activas expuestas en los bundles de JavaScript

Hace ya tiempo que las claves API filtradas dejaron de ser una anécdota; sin embargo, el tamaño real del problema cuando esas credenciales aparecen dentro de código de front-end —específicamente en los bundles de JavaScript— ha permanecido en gran medida invisible hasta estudios recientes. Un equipo técnico desarrolló una técnica nueva para detectar secretos y la aplicó a millones de aplicaciones con un objetivo claro: analizar los artefactos que se despliegan en producción, no solo el código fuente. El hallazgo fue contundente y deja ver una brecha preocupante en la cadena de seguridad de las aplicaciones de una sola página (SPA).

Al aplicar esta metodología a escala, los investigadores generaron un volumen de resultados impresionante: el archivo de salida ocupó más de 100 MB en texto plano y contenía decenas de miles de tokens expuestos que podían corresponder a credenciales reales. En términos concretos, el escaneo rezó la aparición de miles de secretos distintos, distribuidos en cientos de tipos diferentes, y muchos de ellos no eran claves de pruebas ni tokens inactivos; eran credenciales con permiso real sobre servicios en producción. Esa diferencia entre “clave caducada” y “credencial activa con acceso” marca la gravedad del hallazgo.

Entre las exposiciones más dañinas se encontraron tokens de plataformas de repositorios como GitHub o GitLab. Estas credenciales, cuando están activas y con permisos amplios, dan la llave de entrada a código y pipelines, y pueden proporcionar acceso a secretos adicionales utilizados en integraciones de CI/CD, almacenamiento en la nube y claves SSH. También aparecieron claves para herramientas de gestión de proyectos que permiten ver tickets internos y metadatos organizativos, webhooks activos de chat y automatización (entre ellos decenas de Slack y Zapier), APIs de software CAD con información sensible de proyectos, servicios de conversión de documentos, plataformas de inteligencia comercial y acortadores de enlaces que permiten crear y enumerar URLs potencialmente peligrosas.

¿Cómo es posible que todo esto llegue hasta los bundles visibles en producción? La respuesta está en una combinación de fallos en el ciclo de vida del software y en las limitaciones de las herramientas habituales de seguridad. Muchas organizaciones confían en escáneres que operan sobre repositorios o en análisis estático del código fuente (SAST). Estas herramientas son valiosas y detectan credenciales codificadas directamente en los ficheros del repositorio, pero no siempre cubren lo que ocurre más adelante: el proceso de construcción y despliegue puede introducir, transformar o mezclar artefactos de manera que las rutas por las que entran ciertos secretos no coinciden con lo que se inspecta en el control de código.

Por otro lado, los escáneres de infraestructura tradicionales o muchas plantillas de detección automáticas realizan análisis muy simples: solicitan una URL base, inspeccionan la respuesta directa y aplican expresiones regulares para buscar patrones conocidos. Eso funciona en muchos casos, pero tiene un límite evidente: no ejecuta el JavaScript de la página ni descarga los bundles que el navegador carga para renderizar una SPA. Como resultado, los ficheros empaquetados que contienen tokens pueden permanecer fuera del alcance de esas comprobaciones.

Hay herramientas diseñadas para escaneo dinámico (DAST) que sí pueden ejecutar un navegador sin cabeza, autenticar y recorrer la aplicación más a fondo, y por tanto detectan vectores que los escáneres estáticos o de infraestructura no alcanzan. Sin embargo, DAST suele ser más costoso, complejo de configurar y, en la práctica, se aplica a un número reducido de aplicaciones consideradas de alto valor. Mantener un DAST completo para todo el parque de aplicaciones de una empresa es raro, y además muchas implementaciones no llevan incorporadas todas las firmas o expresiones regulares necesarias para identificar la variedad de secretos que pueden aparecer.

Un ejemplo práctico de las limitaciones actuales es la plantilla de detección de tokens personales de GitLab en los repositorios de ProjectDiscovery para Nuclei. Esa plantilla asume una URL base, comprueba la respuesta inicial y, si encuentra un patrón que parece un token, hace una llamada a la API pública para confirmar si está activo. Es una lógica eficaz en contextos concretos, pero no sustituye a la capacidad de analizar todos los recursos que una página carga cuando la visita un navegador real, como los bundles de JavaScript que a menudo son los que contienen los secretos tras la construcción (ejemplo del repositorio: plantilla de Nuclei para tokens personales de GitLab).

Esto deja abierta una zona ciega que ni los escáneres de repositorio ni muchos escáneres de infraestructura cubren, y que DAST sólo aborda si se despliega a gran escala. La consecuencia es que secretos introducidos durante la fase de build o por pipelines de despliegue pueden acabar en artefactos en producción sin que los controles “shift-left” (aquellos que empujan la seguridad hacia fases tempranas como el desarrollo y el repositorio) los detecten.

Ante este panorama la solución no pasa por abandonar las prácticas existentes, sino por complementarlas. Las comprobaciones tempranas en el ciclo de desarrollo y la integración de escaneo de secretos en repositorios y en los entornos de CI/CD siguen siendo imprescindibles —por algo organismos de referencia recomiendan gestión de secretos y detección temprana—. OWASP, por ejemplo, ofrece guías sobre cómo gestionar secretos y reducir el riesgo de exposición en entornos de desarrollo y producción (OWASP Secrets Management Cheat Sheet).

Pero, además, es necesario inspeccionar los artefactos finales que sí llegan a la web: escanear los bundles de JavaScript publicados, simular la ejecución de la SPA con un navegador automatizado para descargar los recursos que el cliente realmente usa, y verificar que no haya tokens ni endpoints sensibles expuestos. Herramientas de escaneo que analicen los ficheros entregados en producción y que realicen spidering de SPAs ayudan a cerrar este hueco. Complementariamente, las plataformas de repositorios públicas han desarrollado funcionalidades de detección de secretos que conviene activar; GitHub, por ejemplo, ofrece servicios de secret scanning integrados para alertar de filtraciones en commits y repositorios (Documentación de GitHub sobre secret scanning).

A nivel de buenas prácticas operativas, la recomendación es minimizar el riesgo mediante la restricción de permisos (principio de menor privilegio), rotación automática de claves comprometi­das y adopción de sistemas de gestión de secretos en los que las credenciales nunca formen parte del código fuente ni de los artefactos estáticos. También conviene revisar el uso de tokens en terceros, limitar su alcance y auditar quién y qué los utiliza. Para tokens específicos de plataformas como GitLab existe documentación sobre el uso y las limitaciones de los personal access tokens que ayuda a diseñar permisos más seguros (GitLab: Personal access tokens).

El riesgo tiende a aumentar a medida que los flujos de trabajo se automatizan y crece el empleo de código generado por IA en pipelines: si las validaciones migran a procesos automáticos sin controles adecuados, es posible que credenciales válidas se inserten en artefactos sin revisión humana suficiente. Por eso conviene que la estrategia incluya escaneo no sólo del código fuente sino también de los paquetes y bundles que llegan a los clientes, y que se integren comprobaciones automatizadas durante la fase de build para detectar y bloquear secretos antes del despliegue.

La lección es clara: la seguridad del frontend no se limita a las políticas aplicadas en el repositorio. Hay que cerrar la ventana que se abre en la construcción y en la entrega de artefactos. Herramientas que combinen análisis estático, dinamizado con navegación real y escaneo de artefactos desplegados permiten detectar problemas que de otra forma quedarán en claro hasta que un atacante los encuentre. Para organizaciones con amplios parques de aplicaciones, la alternativa es arriesgarse a que credenciales críticas permanezcan visibles en producción y, con ello, a una vía de acceso oportunista para actores maliciosos.

Si quieres profundizar en trabajos que abordan específicamente este problema a gran escala o en soluciones comerciales que ya incorporan detección de secretos en bundles de SPA, la investigación publicada por los equipos que estudian este fenómeno y las páginas de proveedores de seguridad ofrecen recursos útiles para entender alcance y mitigaciones. Además de las guías de OWASP y las funcionalidades de los repositorios, revisar las prácticas de gestión de secretos y evaluar la inclusión de escaneos de artefactos en tu pipeline son pasos prácticos y urgentes para reducir la exposición.