TL;DR: por qué no deberías desplegar scripts de analítica en todo el sitio
- La comodidad causó una fuga: Los documentos de incorporación siguen diciendo a los desarrolladores que coloquen las etiquetas de analítica en _document.js y ya está, pero esa comodidad es exactamente cómo Kaiser Permanente envió 13,4 millones de registros de miembros a proveedores externos que nunca debían verlos.
- PCI lo vuelve obligatorio: PCI DSS 4.0 hace que el inventario y la integridad de los scripts sean obligatorios a partir de marzo de 2025. El agente JavaScript de origen propio (first-party) de cside vigila el comportamiento en tiempo de ejecución de cada script de terceros en el 100% de las sesiones, en cada página, con bloqueo autónomo añadido.
- Acota antes de auditar: Antes de la próxima auditoría de tu framework, decide si los píxeles de analítica y marketing realmente necesitan acceso al DOM en tus páginas de inicio de sesión, KYC y cuenta, o si un despliegue limitado a páginas concretas cierra gratis un vector de ataque en la cadena de suministro.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Los scripts de terceros suelen desplegarse en todo el sitio, normalmente inyectados en las etiquetas head de frameworks web como Next.js a través del archivo '_document.js'. Esta implementación generalizada, aunque cómoda para los desarrolladores y a menudo recomendada por las guías de incorporación, hace que estos scripts se ejecuten en todo el sitio. Esto es más sencillo de implementar, pero también introduce riesgos de seguridad y problemas de rendimiento que a menudo se pasan por alto.
La reciente filtración de datos de Kaiser Permanente muestra los peligros de tener scripts de terceros mal gestionados. Como escribimos en nuestro desglose completo del incidente:
El 29 de abril, el gigante sanitario Kaiser Permanente reveló una filtración de datos que afectó a 13,4 millones de miembros actuales y anteriores de su seguro. El incidente tuvo su origen en scripts de terceros gestionados de forma inadecuada. Kaiser Permanente utilizaba códigos de seguimiento para monitorizar cómo sus miembros navegaban por su sitio web y sus aplicaciones móviles. Algunas de estas páginas contenían datos sanitarios sensibles, lo que provocó que los scripts de terceros transmitieran inadvertidamente información a proveedores externos que no debían tenerla. Aunque la brecha no fue resultado de un secuestro de script, pone de manifiesto un descuido importante en la gestión de scripts de terceros.
Pero el problema es más amplio que filtrar información potencialmente sensible a proveedores externos. Los scripts de terceros se usan en todas partes, pero rara vez se examinan, supervisan o protegen.
Los riesgos de desplegar scripts de terceros en todo el sitio
Veamos ahora algunos de los problemas que surgen al desplegar scripts de forma global.
1. Acceso no controlado a los datos
Esto es lo que ocurrió en el caso de Kaiser Permanente. Los scripts de terceros a menudo tienen acceso a datos sensibles en las páginas web cuando se despliegan globalmente. Esto puede incluir entradas de usuario, información de sesión y otros datos confidenciales. Sin controles estrictos, estos scripts pueden filtrar datos a partes no autorizadas, de forma involuntaria o malintencionada. En el caso de Kaiser Permanente y otras entidades sanitarias, los scripts de terceros a menudo no cumplen con la Health Insurance Portability and Accountability Act (HIPAA), lo que convierte una filtración de datos a estos proveedores en un incidente grave.
2. Ataques a la cadena de suministro
Los atacantes pueden comprometer la cadena de suministro web dirigiéndose a servicios de terceros e inyectando código malicioso en los scripts. Estos scripts comprometidos pueden entonces propagar malware, robar datos o realizar otras acciones dañinas en todos los sitios donde estén desplegados. Esto ya es malo de por sí, pero es aún peor cuando los scripts se despliegan globalmente y tienen acceso a más datos y usuarios.
Por supuesto, cside protege contra esto.
3. Aplicaciones web de página única (SPA)
Las SPA no gestionan bien los scripts en absoluto. A menos que un desarrollador realice una recarga completa al navegar a una página sensible, todos los scripts cargados previamente permanecen presentes. Cualquier script de terceros cargado inicialmente sigue ejecutándose y puede acceder a datos sensibles durante toda la sesión del usuario, a menos que la página se recargue por completo, lo que aumenta el riesgo de filtraciones de datos y accesos no autorizados.
4. Riesgos de cumplimiento normativo
Las organizaciones deben cumplir con diversas normativas de protección de datos, como el RGPD, la HIPAA y PCI DSS 4.0. Una gestión inadecuada de los scripts de terceros puede llevar al incumplimiento normativo, lo que conlleva el riesgo de multas cuantiosas y repercusiones legales.
PCI DSS 4.0 exige la supervisión de los scripts de terceros a partir de marzo de 2025, así que ahora es el momento de empezar e implantar cside. Te ayuda a cumplir la normativa y añade bloqueo autónomo por encima para protegerte todavía más.
5. Problemas de rendimiento y estabilidad
Quizás menos complicado, pero sin duda perceptible, los scripts de terceros mal optimizados ralentizan los sitios web. Cualquier tiempo de inactividad o problema con el servicio de terceros puede afectar directamente a la funcionalidad y disponibilidad del sitio anfitrión. Un sitio que carga en 1 segundo tiene una tasa de conversión 3 veces mayor que un sitio que tarda 5 segundos en cargar.
Protégete contra estos problemas
Igual que las directrices de PCI DSS 4.0, somos defensores de la supervisión de seguridad continua y animamos a todos los propietarios de sitios a adoptarla. Creemos que aplicarla a todas las páginas es el enfoque más eficaz.
Puedes hacerlo usando nuestro nivel gratuito. Es de autoservicio, para que cumplas la normativa y estés protegido en cuestión de minutos. Por supuesto, siempre estamos cerca para ayudarte si lo necesitas.
Nuestro script reescribe las fuentes de otros scripts en tu sitio para canalizarlos a través de cside. También realiza algunas detecciones en el lado del navegador. Esto permite a cside mediar en el flujo de solicitudes entre el usuario y el script de terceros sin añadir latencia. En algunos casos, incluso puede mejorar el rendimiento almacenando en caché los scripts estáticos.
Esto ofrece una visibilidad total de cada script servido, en el 100% de las sesiones, en cada página.
Para más información sobre en qué se diferencia nuestro enfoque, lee aquí.
