Por qué esto importa más de lo que parece

Abre la web de tu empresa, pulsa F12 y entra en la pestaña «Red» (Network). Recarga la página y fíjate en cuántos dominios que no son tuyos aparecen en la lista.

Analítica, píxeles de LinkedIn y de Google Ads, el CRM, el chat, el mapa de calor, el formulario embebido, el vídeo, la herramienta de pruebas A/B. En muchas webs de marketing B2B la lista es bastante más larga de lo que el propio equipo imagina.

Cada uno de esos dominios ejecuta código dentro del navegador de tus visitantes, con tu marca delante. Y casi ninguno ha pasado por una revisión de seguridad.

Ese es el riesgo olvidado. En este artículo vemos cómo funciona, cómo se ha explotado en la práctica y qué controles puedes aplicar sin convertir al equipo de seguridad en el departamento que siempre dice que no.

Qué son los scripts de terceros y por qué un gestor de etiquetas los multiplica

Un script de terceros es cualquier fragmento de JavaScript que tu web carga desde un servidor que no controlas: una librería alojada en una CDN, el código de un píxel publicitario, un widget de chat. Cuando el navegador lo recibe, lo ejecuta como si fuera código tuyo.

Un gestor de etiquetas, como Google Tag Manager, añade una capa más. Instalas un único fragmento en la web y, a partir de ahí, el equipo de marketing publica etiquetas desde una interfaz web, sin pasar por desarrollo ni por un despliegue. Esa agilidad es justo lo que se busca, y es también lo que cambia el modelo de riesgo.

Con un gestor de etiquetas, la lista de scripts que se ejecutan en tu web deja de estar en tu repositorio de código. Está en una cuenta externa, la puede modificar cualquier persona con permisos de publicación y puede incluir etiquetas de «HTML personalizado», que no son más que JavaScript arbitrario.

La guía de OWASP sobre gestión de JavaScript de terceros resume bien el problema. Identifica tres riesgos principales: la pérdida de control sobre los cambios en la aplicación cliente, la ejecución de código arbitrario en los equipos de los usuarios y la fuga de información hacia terceros. Señala además que el mayor riesgo es que se comprometa el servidor del proveedor y se inyecte código malicioso en el script original.

Por qué un script de marketing es un objetivo atractivo

Un atacante no necesita entrar en tu servidor si puede entrar en el de un proveedor que ya está dentro de tu web. Hay tres razones por las que este camino resulta tan rentable.

Tiene los mismos privilegios que tu propio código

Un script de terceros puede leer lo que el usuario escribe en un formulario, modificar el contenido de la página, añadir campos falsos, leer las cookies que no estén marcadas como HttpOnly y redirigir al visitante a otra dirección. El navegador no distingue entre «código de la casa» y «código de un proveedor».

Nadie lo revisa como revisa su propio código

El código propio pasa por revisiones, pruebas y, con suerte, algún test de intrusión. El de terceros se incorpora con una copia y pega y se da por bueno. Además, puede cambiar sin que tú hagas nada: el proveedor actualiza su archivo y tu web empieza a ejecutar la versión nueva esa misma tarde.

El efecto multiplicador juega a favor del atacante

Si alguien compromete a un proveedor popular, compromete de golpe a todas las webs que cargan su script. Es más eficiente que atacar sitios uno por uno. Por eso los scripts de terceros son un blanco habitual de los grupos que roban datos de pago directamente desde el navegador, conocidos en conjunto como Magecart.

Cuatro formas en las que se rompe la cadena

1. El proveedor sufre una intrusión

En 2018, el script de un proveedor de chatbot que Ticketmaster utilizaba en su web fue manipulado para capturar los datos de pago de los clientes. El punto débil no estaba en los servidores de la empresa, sino en un componente externo que nadie vigilaba como código propio.

2. El dominio cambia de manos

Un script que hoy es legítimo puede dejar de serlo mañana sin que cambie una sola línea de tu web. Basta con que el dominio que lo sirve caduque o se venda. OWASP ya advertía de este escenario.

El caso más claro es el de Polyfill.io. A principios de 2024, el dominio y el servicio pasaron a manos de una empresa china de CDN llamada Funnull, y más tarde el script servido empezó a inyectar código malicioso. Según SecurityWeek, más de 100.000 webs cargaban ese dominio, y el autor original del proyecto había recomendado dejar de usarlo desde el cambio de propietario. El código redirigía a parte de los visitantes a sitios fraudulentos.

3. Alguien accede a la cuenta del gestor de etiquetas

Quien puede publicar en tu contenedor puede ejecutar código en tu web, sin tocar el servidor y sin dejar rastro en el repositorio. Una cuenta de un excolaborador de agencia que nunca se dio de baja, una contraseña reutilizada sin segundo factor o un permiso de publicación concedido «para salir del paso» son suficientes.

4. Etiquetas olvidadas

La campaña terminó hace dos años y la agencia ya no trabaja con vosotros, pero el píxel sigue cargando. Cada etiqueta huérfana es código que nadie vigila, de un proveedor al que quizá nadie da mantenimiento, y que sigue recibiendo datos de tus visitantes.

Qué se juega un sitio B2B

Es fácil pensar que esto es un problema de tiendas online. Un sitio B2B también tiene mucho que perder:

• Formularios de contacto y de demo que recogen nombre, cargo, correo corporativo y teléfono de personas con poder de decisión.
• Áreas de cliente y portales con acceso a pedidos, presupuestos o documentación.
• Tiendas B2B y páginas de pago o de solicitud de crédito.
• Visitantes que son empleados de empresas concretas. Una redirección a una página falsa se convierte en un phishing dirigido con la marca de tu empresa.

El incidente de British Airways en 2018 no empezó en un gestor de etiquetas, sino con un acceso a la red de la aerolínea. Pero muestra lo que cuesta un script alterado en una web: el código malicioso capturaba los datos de pago mientras los clientes completaban la compra, afectó a unas 400.000 personas y, el regulador británico acabó imponiendo una multa de 20 millones de libras.

Hay además un componente regulatorio. Cuando un script de terceros se carga en tu página, el navegador contacta directamente con ese tercero, que recibe la dirección IP del visitante y, según el caso, la página de origen y las cookies que ya tuviera. Esa transferencia de datos es responsabilidad tuya, también bajo el RGPD. Y si tu web cobra online, el estándar PCI DSS 4.0 exige desde 2025 (requisitos 6.4.3 y 11.6.1) que todos los scripts de la página de pago estén autorizados, justificados e inventariados, y que se detecten los cambios no autorizados.

Controles que funcionan sin frenar al equipo de marketing

La solución no es prohibir los gestores de etiquetas, sino tratarlos como una vía de despliegue de código en producción. Su supervisión debe formar parte del mantenimiento web.

Haz un inventario y asigna un responsable a cada etiqueta

Lista todos los dominios externos que carga cada tipo de página: inicio, blog, formularios, área de cliente. Para cada etiqueta, anota quién la pidió, para qué sirve, qué datos recibe y hasta cuándo se necesita. Revisa la lista cada trimestre y elimina lo que no tenga dueño. Es la medida más barata y la que más reduce la superficie de ataque.

Protege el propio gestor de etiquetas

• Activa la verificación en dos pasos en todas las cuentas con acceso.
• Aplica el mínimo privilegio. Google Tag Manager separa los permisos de lectura, edición, aprobación y publicación; usa esa separación.
• Da de baja de inmediato a los usuarios de agencias y colaboradores que ya no trabajan contigo.
• Exige la revisión de una segunda persona para las etiquetas de HTML personalizado.
• Consulta el historial de versiones tras cualquier cambio inesperado.

Retira las etiquetas de las páginas sensibles

Las páginas de acceso, de pago o con formularios largos no necesitan el píxel de remarketing ni el mapa de calor. Limita ahí las etiquetas a las imprescindibles. Para medir conversiones, suele bastar un evento en la página de confirmación posterior, que no recoge datos delicados.

Define una política de seguridad de contenido (CSP)

Una CSP es una cabecera HTTP que indica al navegador desde qué dominios puede cargar scripts. Un ejemplo básico:

Content-Security-Policy-Report-Only: script-src 'self' https://www.googletagmanager.com

Empieza en modo «solo informe» (Report-Only): el navegador no bloquea nada, pero te avisa de cada script que no está en la lista. Ese primer informe suele revelar dominios que nadie sabía que estaban ahí. Con un gestor de etiquetas, ajustar una CSP estricta requiere pruebas, así que conviene observar antes de bloquear.

Ten presente una limitación: la CSP no puede distinguir entre una etiqueta legítima y una maliciosa publicadas desde un contenedor que ya está autorizado. No sustituye al control de acceso al gestor de etiquetas; lo complementa. Además, una CSP mal configurada puede esquivarse: conviene conocer las técnicas de bypass de CSP para saber qué errores evitar al definirla.

Usa integridad de subrecursos y copias propias para librerías estables

Para archivos que no cambian, como una versión concreta de una librería JavaScript, el atributo integrity permite que el navegador compruebe que lo descargado coincide con lo que esperabas:

<script src="https://cdn.example.com/lib.min.js" integrity="sha384-HASH_DEL_ARCHIVO" crossorigin="anonymous"></script>

Si el archivo cambia, el navegador lo rechaza. Esto no sirve para scripts que cambian por diseño, como los de analítica o el propio contenedor del gestor de etiquetas, pero es muy útil para librerías de apoyo. Todavía mejor: aloja una copia propia. En el caso de Polyfill.io, las webs que lo hacían quedaron fuera del ataque.

Vigila los cambios

Una revisión anual no basta. Configura alertas para cuando aparezca un dominio nuevo en tus páginas críticas, revisa los informes de la CSP y comprueba de forma periódica qué scripts se cargan realmente en producción.

Cómo plantearlo con el equipo de marketing

Estas medidas funcionan si el equipo de marketing las ve como un apoyo y no como un obstáculo. Un acuerdo sencillo suele bastar: cualquier etiqueta nueva se publica en menos de 48 horas, a cambio de responder cinco preguntas.

• ¿Qué proveedor es y desde qué dominio se carga?
• ¿Qué datos recibe?
• ¿Tiene el consentimiento del usuario cuando corresponde?
• ¿En qué páginas se va a cargar?
• ¿Cuándo se revisa o se retira?

Conclusión: ideas clave

Los gestores de etiquetas y los scripts de terceros no son el problema. El problema es que se instalan como una herramienta de marketing y se comportan como código en producción, sin las revisiones que recibe el código propio.

• Todo script de terceros se ejecuta con los mismos privilegios que tu propio código.
• Un gestor de etiquetas saca esa lista de tu repositorio: el acceso a su cuenta es tan crítico como el acceso al servidor.
• Los ataques reales, como Polyfill.io o Magecart, aprovechan la confianza en proveedores y dominios, no fallos de tu web.
• Inventario, mínimo privilegio y menos etiquetas en páginas sensibles son las medidas con mejor relación entre esfuerzo y resultado.
• Una CSP en modo informe y la integridad de subrecursos añaden una capa técnica sin bloquear al equipo.
• Un proceso simple de alta de etiquetas da velocidad a marketing y visibilidad a seguridad.

La próxima vez que alguien pida añadir «solo un píxel más», no hace falta decir que no. Basta con saber quién lo pone, qué datos ve y cuándo se retira.