Secretos que viajan con el bundle: millones de apps exponen tokens en el navegador y cómo detenerlo

Las filtraciones de claves y tokens de API dejaron de ser una rareza. En los últimos años hemos visto cómo secretos que deberían permanecer en entornos cerrados terminan circulando en repositorios públicos, imágenes de contenedor y, con creciente frecuencia, dentro del propio código que se envía al navegador. ¿Por qué siguen produciéndose estas fugas cuando existen tantas herramientas y prácticas para evitarlas? Tras investigar cómo funcionan las distintas aproximaciones a la detección de secretos y desarrollar una comprobación específica para bundles de JavaScript, el resultado fue sorprendente: al analizar a escala millones de aplicaciones se encontraron decenas de miles de tokens expuestos, muchos de ellos activos y con permisos potentes.

Los métodos clásicos para buscar secretos suelen apoyarse en dos pilares: conocer rutas habituales donde se pueden dejar credenciales y aplicar patrones (normalmente expresiones regulares) que identifiquen formatos de tokens conocidos. Esta técnica, plenamente automatizable, da resultados útiles y rápidos, y es la que emplean muchos escáneres de infraestructura. Sin embargo, tiene un límite obvio: si el motor de búsqueda se conforma con pedir la página raíz de un dominio y no reproduce las peticiones que hace un navegador —como la descarga de ficheros JavaScript—, muchos secretos nunca pasan por delante del detector. Un ejemplo real de plantilla que sigue ese patrón puede verse en los repositorios de ProjectDiscovery para Nuclei, donde se describen comprobaciones que inspeccionan respuestas directas a peticiones HTTP concretas y actúan en consecuencia: plantilla de Nuclei para tokens personales de GitLab.

Por otro lado, las pruebas dinámicas de seguridad (DAST) parecen, en teoría, una buena opción para detectar secretos en el front-end porque pueden emular la navegación real, rastrear la aplicación y comprender flujos que requieren autenticación. En la práctica, ejecutar DAST de forma exhaustiva es más costoso y requiere configuración avanzada, por eso muchas organizaciones lo reservan a un número reducido de aplicaciones críticas. Además, no todos los escáneres DAST incorporan la misma amplitud de patrones de detección que herramientas especializadas en búsqueda de secretos.

La verificación estática de código (SAST) es otro elemento del arsenal: analiza el código fuente para prevenir que secretos lleguen a producción y es muy efectiva en muchos escenarios. Pero los bundles de JavaScript empleados en aplicaciones web modernas, sobre todo en las Single-Page Applications (SPA), pueden construirse en etapas posteriores al análisis estático o con procesos de build que inyectan variables. Esto permite que nuevos secretos aparezcan en artefactos compilados sin pasar por los controles que corre SAST, de modo que un análisis puramente estático del repositorio no siempre detecta lo que finalmente se sirve al cliente.

Con estas limitaciones en mente, se diseñó una comprobación orientada a examinar los bundles JavaScript descargables por un navegador. Se puso a trabajar a escala: aproximadamente cinco millones de aplicaciones fueron rastreadas buscando patrones de tokens dentro de los ficheros servidos al cliente. El volcado de resultados superó los 100 MB de texto y arrojó más de 42.000 credenciales coincidentes con 334 tipos distintos de secretos. No todos los hallazgos fueron triados manualmente, pero entre las muestras verificadas aparecieron exposiciones de alto impacto que ilustran bien el problema.

Entre los casos más graves se detectaron tokens para plataformas de repositorios de código. En total aparecieron 688 tokens vinculados a servicios como GitHub y GitLab, y una parte relevante seguía vigente, permitiendo acceso a repositorios privados. En una instancia concreta se localizó un token personal de GitLab embebido en un fichero JavaScript, otorgando permisos amplios sobre la organización, incluidos secretos de pipelines y accesos que facilitan movimientos laterales hacia servicios como AWS o accesos por SSH. La documentación oficial de GitLab sobre tokens personales es un buen punto de referencia para entender los riesgos que conlleva exponerlos: GitLab — Personal access tokens. De forma similar, GitHub mantiene guías sobre la creación y gestión de tokens que conviene conocer: GitHub — Personal access tokens.

Otra exposición notable afectó a claves de API de herramientas de gestión de proyectos. Se localizaron tokens de Linear insertos en código de front-end que permitían leer tickets, proyectos internos y enlaces a integraciones que a su vez podían dar acceso a otros activos y servicios. Más allá de estos ejemplos, la exploración encontró credenciales relacionadas con APIs de software de diseño asistido por ordenador, acortadores de enlaces con capacidad para crear y enumerar URLs, plataformas de email marketing con acceso a listas y campañas, webhooks de plataformas de chat y automatización —entre los que se contabilizaron cientos de endpoints activos de Slack, Microsoft Teams, Discord y Zapier—, conversores de PDF y herramientas de inteligencia comercial que exponían bases de datos de contactos. Estos hallazgos confirman que la superficie de riesgo no se limita a unos pocos proveedores sino que abarca una gran variedad de integraciones y servicios.

¿Qué enseñanzas prácticas se derivan de todo esto? En primer lugar, las medidas de "shift-left" —analizar y prevenir desde las primeras etapas del desarrollo— siguen siendo fundamentales. Herramientas de SAST, escáneres de repositorios, y plugins en IDE detectan muchas malas prácticas antes de que el código salga del entorno de desarrollo. No obstante, no bastan por sí solas: cualquier secreto introducido en fases de build o durante la configuración de despliegue puede eludir esos controles y terminar empaquetado en un bundle servido al navegador.

Por eso resulta esencial incorporar comprobaciones que reproduzcan el comportamiento real de un cliente web: descargar los ficheros JS que la aplicación entrega, inspeccionarlos en busca de patrones de tokens y validar la actividad de las credenciales detectadas. Este enfoque exige mecanismos que interpreten el mismo árbol de recursos que un navegador obtiene al cargar una SPA y que, además, realicen comprobaciones automatizadas para determinar si un token continúa siendo válido. La comunidad de seguridad y las guías de buenas prácticas recogen recomendaciones para gestionar secretos —por ejemplo el OWASP Secret Management Cheat Sheet— que conviene integrar con detecciones en tiempo de ejecución.

En cuanto a mitigaciones concretas, las organizaciones deben evitar, en la medida de lo posible, que cualquier credencial con permisos sensibles llegue al cliente. En su lugar, las aplicaciones deberían delegar llamadas a servicios en servidores controlados, emplear proxys que oculten claves, utilizar tokens de corta vida y aplicar el principio de menor privilegio. Además, activar y complementar el escaneo de secretos que ofrecen proveedores como GitHub —ver su servicio de detección de secretos— ayuda a interceptar filtraciones en el código y en los artefactos publicados: GitHub — Secret scanning.

El panorama evoluciona también por la creciente automatización y el uso de código generado por herramientas de IA: si los pipelines automatizados no están configurados para proteger secretos, el riesgo de introducir credenciales en artefactos compilados aumentará. La solución pasa por combinar chequeos estáticos en el flujo de desarrollo, escaneos en repositorio, controles durante la compilación y detección dinámica que simule la descarga e inspección de los bundles que llegan al navegador. Para las aplicaciones SPA concretamente, esto implica incorporar spidering y descarga de recursos estáticos como parte del proceso de seguridad, en lugar de limitarse a pedir únicamente la página inicial.

Detectar y eliminar secretos expuestos en bundles no es una tarea trivial, pero la evidencia muestra que es imprescindible: cuando se analizaron millones de aplicaciones aparecieron decenas de miles de tokens expuestos y centenares de tipos distintos de secretos. Adoptar una estrategia multi-capa, actualizar procesos de CI/CD para no inyectar credenciales en artefactos públicos, y ejecutar escaneos que reproduzcan la experiencia real del navegador son pasos necesarios para reducir significativamente este riesgo. Si quieres profundizar en las diferencias entre análisis estático y dinámico y entender mejor cuándo emplear cada técnica, los recursos de OWASP sobre análisis de seguridad son un buen punto de partida: OWASP — Source code analysis y OWASP — Dynamic analysis.

En resumen, el problema está claro: los secretos no deberían viajar hasta el navegador, pero con los procesos de build, despliegue y automatización actuales eso sigue ocurriendo. La respuesta no es una sola herramienta sino una combinación de buenas prácticas, controles en el pipeline y detección que inspeccione exactamente lo que el navegador descarga. Solo así podremos reducir la probabilidad de que un token comprometido sea la puerta de entrada a activos mucho más valiosos.