La JavaScript injection es la inserción de script controlado por un atacante en una página web de modo que se ejecute en los navegadores de los visitantes con los mismos privilegios que el código propio de la página. Una vez en ejecución, el script inyectado puede leer el DOM, capturar lo que los usuarios escriben y enviar datos a cualquier parte — el mecanismo detrás del formjacking, de Magecart y de la mayoría de los robos de datos client-side.
¿Cómo se inyecta JavaScript?
| Vía de inyección | Cómo funciona | Quién está comprometido |
|---|---|---|
| XSS (reflejado / almacenado / basado en DOM) | Un fallo en el sitio permite que la entrada del atacante se ejecute como script | El código propio del sitio |
| Supply chain de terceros | Un proveedor cuyo tag cargas distribuye código malicioso — por brecha o adquisición | El proveedor (Polyfill.io es el caso canónico) |
| Dominios caducados / de imitación | Un atacante se apodera de un dominio desde el que tu página aún carga scripts | La cadena de dependencias |
| Abuso del tag manager | Una cuenta de tag manager comprometida inyecta "un tag más" | Tu stack de marketing |
| Malware / extensiones client-side | El script se inyecta en la máquina del visitante, en todos los sitios | El navegador del visitante |
La primera vía es un fallo de código que puedes corregir. Las tres del medio son fallos de confianza: el código fue invitado a entrar. Una página moderna ejecuta docenas de scripts de terceros, y cada uno de ellos es un vector de inyección con todos los privilegios de la página — el problema central de la seguridad client-side.
Qué hacen los scripts inyectados
El código inyectado no tiene ninguna frontera de privilegios que lo separe del tuyo. En ataques observados, roba formularios de pago carácter a carácter, recolecta credenciales de páginas de inicio de sesión, superpone campos de pago falsos sobre los legítimos, secuestra ingresos de afiliados, redirige sesiones y envía los datos robados a la infraestructura del atacante — a menudo dominios con nombres pensados para parecerse al adtech habitual de tu pestaña de red.
Prevención: reducir las vías
- Corrige la clase XSS: codificación de la salida, sinks seguros, sanitización, Trusted Types.
- Restringe los orígenes con una Content Security Policy: una CSP estricta basada en nonces bloquea orígenes de script no autorizados — con límites conocidos: no puede juzgar lo que hace un script permitido después de cargarse.
- Fija lo que puedas: Subresource Integrity para dependencias estáticas; minimiza el radio de impacto del tag manager.
- Reduce el árbol de dependencias: cada script de terceros eliminado es una vía de inyección eliminada.
Detección: vigilar el tiempo de ejecución
La prevención reduce la probabilidad; no puede alcanzar el compromiso de un proveedor de confianza. La detección tiene que ocurrir donde aterriza la inyección — el navegador. La monitorización de scripts de cside inventaría cada script que se ejecuta en sesiones reales, analiza los payloads y alerta sobre dominios nuevos, código modificado y flujos de datos inesperados. En las páginas de pago, ese inventario en tiempo de ejecución es además un requisito de cumplimiento: los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 existen precisamente porque el script inyectado en la página de pago es invisible para cualquier control del lado del servidor.
