Los scripts de terceros suelen desplegarse en todo el sitio, generalmente 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 frecuentemente recomendada en las guías de incorporación, hace que estos scripts se ejecuten en todo el sitio. 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 análisis 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 una gestión inadecuada de scripts de terceros. Kaiser Permanente utilizaba códigos de seguimiento para monitorizar cómo sus miembros navegaban por su sitio web y aplicaciones móviles. Algunas de estas páginas contenían datos sanitarios sensibles, lo que llevó a que los scripts de terceros transmitieran inadvertidamente información a proveedores externos que no deberían haberla recibido. Aunque la brecha no fue consecuencia de un secuestro de script, pone de manifiesto una grave negligencia en el manejo de scripts de terceros.
Pero el problema va más allá de filtrar información potencialmente sensible a proveedores externos. Refleja la realidad de que los scripts de terceros se usan con frecuencia, pero rara vez se examinan o supervisan. Y aún menos se protegen.
Los riesgos de desplegar scripts de terceros en todo el sitio
Ya que hemos visto por qué la gente suele desplegar scripts de forma global, analicemos algunos de los problemas que esto genera.
1. Acceso no controlado a datos
Esto es exactamente lo que ocurrió en el caso de Kaiser Permanente. Los scripts de terceros desplegados globalmente suelen tener acceso a datos sensibles en las páginas web, como entradas de usuario, información de sesión y otros datos confidenciales. Sin controles estrictos, estos scripts pueden filtrar datos a partes no autorizadas, ya sea de forma accidental o malintencionada. En el caso de Kaiser Permanente y otras entidades del sector sanitario, los scripts de terceros frecuentemente no cumplen con la Health Insurance Portability and Accountability Act (HIPAA), lo que convierte cualquier 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 apuntando a servicios de terceros e inyectando código malicioso en los scripts. Estos scripts comprometidos pueden propagar malware, robar datos o realizar otras acciones dañinas en todos los sitios donde estén desplegados. Esto ya es grave de por sí, pero el problema se agrava 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 (SPAs)
Las SPAs no gestionan bien los scripts en absoluto. A menos que el desarrollador fuerce una recarga completa al navegar a una página sensible, todos los scripts cargados previamente permanecen activos. Cualquier script de terceros cargado inicialmente sigue ejecutándose y potencialmente accediendo a datos sensibles durante toda la sesión del usuario, salvo que se produzca una recarga completa de la página, 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, HIPAA y PCI DSS 4.0. Una gestión inadecuada de los scripts de terceros puede derivar en incumplimientos que acarreen multas elevadas y consecuencias legales.
Con PCI DSS 4.0 exigiendo la supervisión de scripts de terceros a partir de marzo de 2025, ahora es el momento de empezar e implementar cside. No solo te ayuda a cumplir la normativa, sino que va más allá al introducir bloqueo autónomo para una protección más sólida.
5. Problemas de rendimiento y estabilidad
Quizás menos crítico, 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 uno que tarda 5 segundos en cargar.
Protégete contra estos problemas
Al igual que las directrices de PCI DSS 4.0, somos defensores de la monitorización continua de seguridad 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 autoservicio y te permite cumplir la normativa y estar protegido en cuestión de minutos. Por supuesto, siempre estamos disponibles para ayudarte si lo necesitas.
Nuestro script reescribe las fuentes de otros scripts en tu sitio para canalizarlos a través del proxy de cside. También realiza 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 proporciona visibilidad total sobre los scripts servidos, en el 100% de las sesiones y en todas las páginas.
Para más información sobre cómo nuestro enfoque se diferencia del resto, léelo aquí.
