Los scripts de terceros son un riesgo de cadena de suministro
Un script de terceros es código que no escribiste, servido por una empresa que no controlas, ejecutándose dentro de tus páginas con las sesiones de tus usuarios: en términos de cadena de suministro, es una dependencia que puede cambiar su propio código en cualquier momento, sin publicación, sin revisión y sin aviso. En octubre de 2026 ese riesgo abstracto se convirtió en una pérdida concreta, según las crónicas, cuando un script de monitorización de rendimiento cargado por un importante sitio de negociación fue intercambiado por uno construido para drenar a sus usuarios. Este artículo recorre lo que se contó, qué detiene realmente Subresource Integrity, por qué fijar una versión precede a calcular su hash, cuándo el autohospedaje es la mejor respuesta y la rutina corta de auditoría que mantiene honesto el inventario.
Qué pasó en Polymarket, según las crónicas
El 29 de octubre de 2026, según las crónicas, el sitio internacional de Polymarket puso la negociación en modo de solo cancelación después de que los usuarios informaran de que los fondos salían de sus cuentas, y la negociación se reanudó aproximadamente una hora después. Las propias declaraciones de la empresa, según se contó, atribuyeron el incidente a un proveedor externo comprometido, dijeron que el asunto se había remitido a las fuerzas del orden y prometieron resarcir a los usuarios afectados. Los informes basados en el análisis posterior al incidente de la empresa, del 30 de octubre, situaron lo sustraído en el ataque en unos 2,7 millones de dólares, con reembolsos totales de 3,9 millones una vez incluidos los pagos de buena voluntad por las pérdidas causadas por la pausa de la negociación; análisis independientes en cadena citados en la cobertura rastrearon una cifra similar, alrededor de 2,7 millones, repartida entre varios cientos de carteras. Ninguna de esas cifras está verificada de forma independiente aquí: son las cifras de las crónicas, y este artículo las trata como tales.
El mecanismo, según se contó, es la parte que se generaliza. Los investigadores citados en la cobertura vincularon el código malicioso con el script de monitorización de usuarios reales (RUM) de un proveedor de rendimiento web: un archivo pequeño cuyo único trabajo es medir la velocidad de carga de las páginas en los navegadores de los visitantes, incrustado por cliente desde el CDN del proveedor. Ese archivo, según las crónicas, fue sustituido por una carga escrita específicamente para el sitio objetivo: trabajaba dentro de sesiones iniciadas, usaba la propia maquinaria de negociación del sitio ya presente en la página y movía posiciones y fondos a un destino controlado por el atacante. Según las crónicas, no hubo ningún fallo de contrato inteligente ni contraseñas o claves privadas robadas: el script intercambiado simplemente era la página, en lo que al navegador respecta. Que cada detalle de ese relato sobreviva a un escrutinio posterior es, para la lección, irrelevante: la forma del ataque —un archivo de proveedor, intercambiado una vez, ejecutado por cada visitante— es la forma estándar de esta clase de incidentes.
Un script de terceros es tu código, con el proceso de publicación de otro
No hay ninguna caja de arena en una etiqueta script clásica. El código cargado desde el CDN de un proveedor se ejecuta en tu origen con el mismo acceso que tu propio paquete: puede leer y cambiar el DOM, leer valores de formularios mientras se escriben, llamar a tus API con la sesión del usuario y enviar lo que encuentre a cualquier parte. La guía de OWASP sobre JavaScript de terceros nombra los tres riesgos sin rodeos —pérdida de control sobre los cambios de la aplicación cliente, ejecución de código arbitrario en los sistemas cliente y divulgación de información sensible a terceros— y los tres se derivan de ese único hecho. Tu proceso de revisión, tu congelación de código y tu comité de cambios terminan en tu propia construcción; el archivo del proveedor puede editarlo el proveedor, un atacante que comprometa al proveedor o quien vuelva a registrar el dominio del proveedor si alguna vez caduca.
Esa asimetría es la razón por la que «confiamos en este proveedor» no es un control. La confianza decide de quién es el script que aceptas hoy; no dice nada de lo que esa URL servirá mañana, y no te da ninguna señal cuando el contenido cambia. Los controles que funcionan son los que eliminan la confianza (servir el archivo tú mismo), la restringen (una Content-Security-Policy que limite qué puede hacer cualquier script y adónde puede enviar datos) o la verifican mecánicamente en cada carga —que es para lo que sirve Subresource Integrity—. Empieza por el inventario: no puedes aplicar ninguno de los tres a scripts que no sabes que tienes, y la mayoría de los sitios tienen más de los que sus propietarios esperan una vez contadas las etiquetas de marketing, los widgets de soporte y los códigos de monitorización.
Qué detiene SRI — y qué no detiene
Subresource Integrity es un mecanismo del navegador, especificado por el W3C y documentado por MDN: la página declara el hash criptográfico del archivo que espera en el atributo integrity de la etiqueta, el navegador calcula el hash de lo que realmente descargó y, ante cualquier diferencia, se niega a ejecutar el archivo. Para un archivo de otro origen, la etiqueta también necesita crossorigin="anonymous" y el servidor debe enviar cabeceras CORS, para que el navegador pueda hacer la comprobación. Aplicado a una biblioteca fija, SRI convierte un intercambio silencioso en un fallo ruidoso: el archivo que llega o es, byte a byte, el archivo que revisaste, o no se ejecuta en absoluto. Si el script de monitorización del incidente relatado hubiera sido un archivo fijo cargado de esa manera, una carga intercambiada habría fallado la comprobación en lugar de ejecutarse en las sesiones de los usuarios —ese condicional es la forma honesta de la afirmación, porque si ese código concreto era susceptible de hash es una cuestión sobre un archivo dinámico por cliente, que es exactamente el caso difícil de más abajo—.
Lo que SRI no detiene es igual de importante. No ayuda con scripts cuyo contenido se supone que debe cambiar —contenedores de gestores de etiquetas, cargadores de personalización y consentimiento, archivos generados por cliente— porque no hay ningún hash estable que fijar. No juzga el archivo al que calculaste el hash: un script entregado fielmente puede seguir siendo curioso, descuidado o malicioso por diseño, y SRI lo verificará encantado para siempre. No cubre los scripts inyectados en tiempo de ejecución por otros scripts, no protege los archivos propios servidos desde tu propia infraestructura y no hace nada sobre los datos que un script legítimo recoge una vez que se ejecuta. SRI es una garantía mecánica —estos bytes exactos, o nada— y gana su lugar junto a CSP, la revisión de proveedores y la minimización de cuántos terceros obtienen acceso a nivel de sesión desde el principio, no en lugar de ellos. La comprobación de cabeceras de seguridad de este sitio califica el lado CSP de esa pareja.
Fija la versión, o el hash no podrá sostenerse
SRI tiene una condición previa que hace fracasar más auditorías que la malicia: la URL debe devolver siempre los mismos bytes. Un hash fijado sobre una dirección latest, una versión mayor flotante o un archivo por cliente que el proveedor regenera es un hash que se rompe en cuanto el proveedor publica una actualización —y los equipos a los que un fallo de SRI autoinfligido ha despertado una vez tienden a quitar el atributo en lugar de arreglar la dirección, dejando la página peor que sin medir—. El orden duradero es el inverso: primero cambia la URL para que nombre la versión exacta ([email protected], /v2.4.0/), revisa esa versión una vez y luego calcula el hash de ese archivo exacto. Las subidas de versión se convierten entonces en eventos deliberados —URL nueva, hash nuevo, un commit— en lugar de cambios ambientales que descubres por tus usuarios.
Fijar tiene un coste, y la honestidad exige nombrarlo: una biblioteca fijada ya no recibe parches de seguridad silenciosos del proveedor, así que fijar crea el deber de seguir los lanzamientos y subir de versión a propósito, el mismo deber que lleva cualquier dependencia vendorizada. Es un deber manejable —las notas de lanzamiento y un recordatorio de calendario lo cubren— y es estrictamente mejor que la alternativa a la que sustituye, en la que las actualizaciones llegan sin revisar al ritmo del proveedor y las roturas llegan sin anunciar al tuyo. Trata la pareja como una sola práctica: la fijación hace el contenido direccionable, el hash lo hace verificable, y la auditoría se asegura de que ninguno de los dos se haya podrido en silencio —una cadena de versión eliminada por una migración de CMS es tan común como un hash ausente, y solo un poco más difícil de notar a simple vista—.
Autohospedaje, y la rutina de auditoría
Para los scripts que más importan hay una opción más contundente: servir el archivo tú mismo. El autohospedaje elimina por completo el servidor, la cuenta y el dominio del proveedor de tu cadena de suministro en tiempo de ejecución, permite que tu canal de despliegue normal revise y calcule el hash del archivo, y sigue funcionando cuando el CDN del proveedor no lo hace. Las contrapartidas son reales: renuncias a la caché perimetral del proveedor y a las actualizaciones automáticas, asumes el deber de enviar tú mismo sus correcciones de seguridad, y las licencias de algunos proveedores o sus archivos generados por cliente simplemente no lo permiten —así que la división sensata es por criticidad: autohospeda las bibliotecas pequeñas y fijas en las páginas sensibles; fija y calcula el hash de lo que se quede en un CDN; gobierna (con restricciones de publicación, revisión de cambios y CSP) las etiquetas dinámicas que no pueden fijarse ni hospedarse; y elimina, a la vista, cualquier script que nadie pueda justificar. Cada script eliminado es una cadena de suministro que ya no tienes—.
La rutina que mantiene esto cierto es lo bastante corta como para ejecutarla de verdad. Trimestralmente —y tras cualquier rediseño, migración de CMS o proveedor nuevo— ejecuta la auditoría de scripts de terceros y SRI sobre tus plantillas de página clave: lista cada script al que el HTML estático hace referencia, cuáles son de terceros, cuáles carecen de integridad y cuáles no están fijados, y calcula un sha384 listo para pegar para los primeros hashes ausentes que pueda obtener. Corrige por orden de impacto —primero las páginas de sesión, pagos y datos personales—, comprueba después las capas de transporte y cabeceras con el calificador SSL y la comprobación de cabeceras, y termina en el gestor de etiquetas, cuyos scripts inyectados en tiempo de ejecución una auditoría estática no puede ver: revisa su lista de publicadores y su historial de cambios con la misma sospecha que darías a un registro de despliegues. Quince minutos por trimestre, frente a una clase de incidentes cuyo coste relatado, en el caso anterior, ascendió a millones en aproximadamente una hora.