Auditoría de scripts de terceros y SRI
Cada script de terceros que carga tu página se ejecuta con todos los privilegios de tu página: puede leer el DOM, observar lo que se escribe en los formularios y actuar dentro de las sesiones de tus visitantes. Esta auditoría obtiene el HTML estático de una página, lista cada script externo al que hace referencia, marca cuáles son de terceros, cuáles llevan un hash de Subresource Integrity (SRI) y cuáles están fijados a una versión exacta — y, para los scripts de terceros sin integridad, calcula el hash sha384 para que puedas pegarlo directamente en la etiqueta.
Última actualización:
¿Te preocupa que un script de un proveedor en tu sitio cambie o caiga? Vigílalo gratis con myeventwatch — alertas de caducidad y caídas, sin tarjeta.
Qué comprueba esta auditoría — y qué no puede ver
El comprobador obtiene la página una vez y analiza el HTML que se le sirve: solo el HTML estático. Cada <script src> de ese marcado se lista con su host, se clasifica como propio cuando el host coincide con el dominio registrable de tu página y como de terceros cuando no, y se comprueban los dos atributos que deciden si el navegador puede protegerte: integrity, el hash SRI que el navegador verifica antes de ejecutar el archivo, y crossorigin, que una comprobación SRI entre orígenes necesita para funcionar. También se evalúa la versión de la URL: un script direccionado como [email protected] o /v2.4/ está fijado, mientras que una dirección latest o sin versión es un blanco móvil cuyo contenido puede cambiar en cualquier momento sin que nadie toque tu sitio.
Ten clara la frontera, porque importa: la v1 analiza solo el HTML estático de la página — los scripts inyectados en tiempo de ejecución por JavaScript no están cubiertos. Los gestores de etiquetas, las herramientas de consentimiento y los widgets de chat crean habitualmente elementos script desde código después de que la página carga, y un análisis estático nunca los ve. Trata esta auditoría como el inventario de lo que tus plantillas y tu CMS referencian directamente —normalmente la parte mayor y más reparable del problema— y audita los contenedores del gestor de etiquetas por separado, en la vista previa y el historial de cambios del propio gestor. Los scripts en línea (bloques sin src) se cuentan como un dato en el resultado, porque no pueden llevar SRI en absoluto; la guía complementaria explica qué hacer con ellos.
La columna del hash: calculado, nunca adivinado
Para los scripts de terceros que carecen del atributo integrity, el comprobador obtiene el propio script —por la misma ruta de obtención protegida contra SSRF que usan todos los comprobadores de este sitio, con un límite de los 15 primeros scripts de ese tipo y 512 KB cada uno— y calcula su hash SHA-384. Cuando la obtención tiene éxito, la celda SRI muestra el fragmento completo, integrity="sha384-…", listo para pegarlo en tu etiqueta junto a crossorigin="anonymous". Un hash solo se muestra cuando el script se obtuvo de verdad. Si la obtención falló, el archivo era demasiado grande o el script quedó más allá del límite de 15, la celda muestra esa nota en su lugar —nunca un marcador ni un valor adivinado— y la solución es generar el hash en tu propia cadena de construcción, donde el archivo exacto está a mano.
Comprobaciones relacionadas: la comprobación de cabeceras de seguridad califica las cabeceras de respuesta —incluida la Content-Security-Policy, la socia natural de SRI—, el calificador SSL cubre el transporte por el que llegan esos scripts, y el artículo complementario los scripts de terceros son un riesgo de cadena de suministro recorre un incidente real, qué detiene SRI y qué no, y una rutina de auditoría repetible.
Cómo deben leerse los veredictos: un script de terceros con integridad y versión fijada es el caso sano —el navegador rechazará un archivo intercambiado o editado—. Un script de terceros sin integridad no es automáticamente malicioso; está desprotegido, lo que significa que su contenido es lo que su host sirva hoy, y tu única advertencia de un cambio sería el daño. Las direcciones sin fijar merecen la misma sospecha que los hashes ausentes, porque un hash SRI sobre una URL latest se rompe en cuanto el proveedor publica una actualización —por eso ambos hallazgos se informan lado a lado, y por eso la corrección duradera es siempre la pareja: fija la versión exacta y luego calcula el hash de ese archivo exacto—.
Los datos que muestra esta página
| De terceros | Un script cuyo dominio registrable difiere del de la página: código servido por otro, ejecutándose con los privilegios de tu página. |
| Integridad (SRI) | Si la etiqueta lleva un atributo integrity: un hash criptográfico que el navegador comprueba antes de ejecutar el archivo, rechazándolo ante cualquier diferencia. |
| Crossorigin | Si la etiqueta lleva el atributo crossorigin que una comprobación SRI entre orígenes requiere; sin él, los navegadores no pueden aplicar SRI a la carga. |
| Fijado | Si la URL nombra una versión exacta ([email protected], /v2.4/) en lugar de una dirección latest flotante o sin versión cuyo contenido puede cambiar en silencio. |
| SRI calculado | Para los scripts de terceros sin integridad, el hash sha384 que el comprobador calculó obteniendo el archivo de verdad —se muestra solo tras una obtención correcta, para los 15 primeros scripts de ese tipo—. |
Preguntas frecuentes
¿Ve esta auditoría todos los scripts que ejecuta mi página?
No —y la página lo dice claramente: la v1 analiza solo el HTML estático de la página, así que los scripts inyectados en tiempo de ejecución por JavaScript no están cubiertos. Los gestores de etiquetas, las herramientas de pruebas A/B, los banners de consentimiento y los widgets de chat suelen inyectar scripts tras la carga; audítalos en el gestor de etiquetas o con el panel de red de un navegador. Lo que esta auditoría cubre por completo es cada script al que tu HTML servido hace referencia directamente, que es donde viven las bibliotecas, los widgets de CDN y los códigos de monitorización.
¿De dónde sale el hash de la columna SRI?
El comprobador obtiene el propio archivo del script y calcula su hash SHA-384, para los scripts de terceros sin atributo integrity: los 15 primeros, hasta 512 KB cada uno. Un hash solo se muestra cuando el script se obtuvo de verdad: si la obtención falló, el archivo era demasiado grande o se alcanzó el límite, la celda muestra esa nota en lugar de un hash. Pega el fragmento en tu etiqueta script junto con crossorigin="anonymous" y vuelve a ejecutar la auditoría tras cualquier cambio de versión: una versión nueva significa un hash nuevo.
El script de mi gestor de etiquetas no puede tener un hash fijo. ¿Y entonces?
Correcto: un contenedor de gestor de etiquetas está diseñado para cambiar, así que SRI no puede fijarlo, y lo mismo vale para cualquier script cuyo propósito entero es cargar código cambiante. Para esos, los controles son otros: restringe quién puede publicar en el contenedor, revisa su historial de cambios como cambios de código, cárgalo solo en las páginas que lo necesitan y usa una Content-Security-Policy para limitar qué pueden hacer los scripts inyectados y adónde pueden enviar datos. SRI protege las bibliotecas fijas; la gobernanza protege las dinámicas.
¿Es una emergencia que falte un atributo integrity?
Es una exposición permanente, no un incidente. Casi seguro que el script es el archivo que el proveedor pretende servir hoy; el problema es que nada detendría ni señalaría un archivo distinto mañana, tras una intrusión en el proveedor, una cuenta secuestrada o un dominio caducado. Orden de corrección: primero los scripts en páginas con inicios de sesión, pagos o datos personales; después, bibliotecas fijadas y con hash en todas partes; por último, la cola larga. Cada corrección es un cambio de una línea en la etiqueta una vez fijada la versión.
¿Por qué la columna de fijación llama a un script «latest» o «sin versión»?
El veredicto de fijación es una lectura heurística de la URL: un segmento con aspecto de versión, como @1.2.3 o /v2.4/, cuenta como fijado; un segmento latest explícito cuenta como flotante; y una URL sin versión en ninguna parte cuenta como sin versión. Se etiqueta como heurística porque solo el proveedor conoce su esquema de versiones —pero el punto de seguridad no depende de la etiqueta: si los bytes en esa URL pueden cambiar sin que la URL cambie, un hash SRI no puede sobrevivir, así que primero fija y luego calcula el hash—.