En julio de 2025, alguien registró un dominio que había pertenecido a una red de distribución de contenidos. La CDN había cerrado años antes y el dominio desde el que servía sus recursos había expirado. Lo que no había perdido eran sus llamadores.
Miles de sitios web, repositorios de código y páginas de documentación todavía contienen referencias hard-coded a nombres de host bajo ese dominio.
El nuevo propietario tiene DNS comodín en todo el dominio, y cualquier nombre de host bajo él ahora resuelve a la infraestructura que esa persona controla. Hoy el apex sirve una página de descarga de medios cargada de anuncios, lo cual no tiene nada de especial.
Lo extraordinario es que la decisión sobre qué cargan a continuación esas miles de páginas pertenece a un desconocido, y nadie involucrado ha sido notificado, porque desde fuera nada se ha roto.
Este patrón no es hipotético, ni tampoco inaudito. En junio de 2024, el dominio polyfill.io —un shim de JavaScript incrustado en más de 110.000 sitios— cambió de propietario y comenzó a servir redirecciones condicionales a visitantes móviles. Los sitios que lo ejecutaban no habían sido hackeados; simplemente habían externalizado una etiqueta <script> años antes y nunca revisaron esa decisión.
Ambos casos comparten un problema para el que la mayoría de los equipos de seguridad no tiene control alguno: el código malicioso nunca estuvo en su servidor, y llegó mucho después de que ocurriera el último despliegue.
Las herramientas de seguridad miran donde no deben
El análisis estático, el escaneo de dependencias y el análisis de composición de software examinan lo que una organización construye y envía. Pero un script de terceros no es nada de eso. Lo descarga el navegador del visitante, desde un servidor que la organización no ejecuta ni controla, en vivo, en cada vista de página.
Eso lo hace excepcionalmente hostil a las pruebas convencionales, porque la respuesta puede variar según la geografía, el agente de usuario, el referente, la hora del día y la sesión. Un crawler que extrae el archivo una vez desde un rango de IP de centro de datos recibe una versión limpia; el comprador en una red móvil de otro país recibe algo más siniestro.
Mientras tanto, el script de terceros ostenta los mismos privilegios que tu código de primera parte. Puede leer el DOM, leer los campos de formulario carácter a carácter mientras se escriben, leer cookies y almacenamiento local, y hacer peticiones salientes a donde quiera.
Los ataques del lado del cliente del tipo Magecart no requieren una brecha en el servidor en absoluto; requieren que una etiqueta de script aprobada empiece a comportarse de forma diferente.
El navegador lo ve todo
Hay un observador que está presente de forma fiable en cada una de esas vistas de página: el navegador que ejecutó el código. La Política de Seguridad de Contenidos (CSP) suele discutirse como defensa contra el cross-site scripting, y lo es, pero su segunda función es más útil para un equipo de seguridad que aún no sabe qué código está ejecutando. Una CSP puede controlar qué código tiene permitido ejecutarse en tu web, bloquear el código no autorizado y avisarte cuando eso ocurre.
Esas alertas provienen de sesiones reales, en geografías reales, de tus usuarios reales en sus dispositivos reales. Una carga maliciosa que solo se activa para usuarios autenticados en un país concreto sigue siendo reportada, porque el navegador que la ejecutó es el que envía la alerta.
Esto no es un beneficio teórico. En septiembre de 2026, estas alertas recopiladas por Report URI sacaron a la luz un clúster de sitios de comercio electrónico comprometidos que ejecutaban una campaña de ingeniería social de la familia “ClickFix”.
Cargas codificadas en Base64 habían sido plantadas dentro del contenido del CMS tras un compromiso administrativo, encadenando a través de un redirector hacia una superposición falsa de “verifica que eres humano” que colocaba un comando de PowerShell en el portapapeles de la víctima y lo persistía como tarea programada.
Los nombres de host controlados por el atacante aparecieron en alertas de los navegadores de las víctimas mientras varios de esos dominios seguían siendo calificados como limpios por servicios de reputación convencionales. Ningún escáner había marcado las páginas, porque en el servidor estaban bien.
Puedes empezar con CSP sin bloquear nada
La objeción habitual es que una Política de Seguridad de Contenidos romperá el sitio, pero en modo solo-informe no puede. Content-Security-Policy-Report-Only no aplica nada, no bloquea nada y no cambia ningún comportamiento; solo informa de lo que una política habría bloqueado.
Eso convierte el primer despliegue en un ejercicio de medición seguro y permite recopilar todos los datos necesarios sobre qué código se está ejecutando en tu sitio. Para la mayoría de las organizaciones, esa lista es mucho más larga de lo que esperaban.
El cumplimiento normativo lo convirtió en obligación
Para cualquiera que maneje pagos con tarjeta en su sitio, este argumento ya está resuelto. Los requisitos 6.4.3 y 11.6.1 de PCI DSS v4.0.1 dejaron de ser buenas prácticas y se convirtieron en obligatorios el 31 de marzo de 2025.
Juntos, exigen que cada script en una página de pago esté autorizado, que su integridad esté asegurada, que exista un inventario escrito con justificación de negocio, y que un mecanismo detecte y alerte sobre modificaciones no autorizadas del contenido de la página de pago y las cabeceras HTTP.
Un QSA puede y va a pedir el inventario, el mecanismo de alerta y el rastro de evidencia que produjo. Report URI puede darte los tres.
¿Cómo se ve un despliegue que funciona?
Despliega y recopila datos iniciales durante una semana. Construye tu inventario a partir de lo reportado. Monitoriza los cambios a lo largo del tiempo y aprueba o deniega esos cambios.
Un rastreo diario durante diez años de los primeros millones de sitios muestra que la adopción de CSP creció más de un 12.000% a lo largo de la década, a medida que las organizaciones van comprendiendo los beneficios que aporta.
Ese crecimiento refleja un cambio más amplio en dónde necesitan visibilidad las organizaciones: no solo sobre lo que despliegan, sino sobre qué código ejecutan realmente los navegadores de sus usuarios.
¿Dónde encaja Report URI?
Report URI es una plataforma de seguridad del lado del cliente que responde a las preguntas que un equipo de seguridad no puede responder de otro modo sobre su propio sitio: ¿qué terceros están ejecutando código en tus páginas? ¿Cuáles han cambiado desde ayer? ¿Cuáles están tomando datos o comunicándose con infraestructura conocida como hostil?
Los scripts servidos a usuarios reales se hashean y archivan, de modo que los cambios pueden identificarse e investigarse a posteriori. Los nombres de host se verifican contra inteligencia de amenazas, y las políticas se monitorizan en busca de desviaciones, cerrando la brecha entre lo que aprobaste y lo que realmente se ejecuta en tu sitio.
El despliegue no añade JavaScript a tu página ni ningún agente, módulo o SDK a la pila.
El primer paso es fácil: añade una cabecera de respuesta HTTP y lee qué datos vuelven en las próximas 48 horas. La lista de cosas que ejecutan código en los navegadores de tus clientes rara vez es la lista que nadie esperaba.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
