En resumen
Qué se comprueba
si los recursos cargados desde dominios ajenos declaran el atributo integrity.
Qué protege
impide que un archivo alterado en el servidor del proveedor se ejecute dentro de tu web.
Severidad en Wakaris
Importante. Aparece en el 89 % de las páginas analizadas.
Requisito imprescindible
además del resumen criptográfico, la etiqueta necesita crossorigin.
Qué es y qué mide este hallazgo
Este hallazgo salta cuando tu página carga un recurso alojado en un dominio ajeno —normalmente un script o una hoja de estilo servida desde una red de distribución de contenidos— sin declarar el atributo integrity en la etiqueta que lo invoca.
Ese atributo es la pieza central de Subresource Integrity, un mecanismo estándar de los navegadores. La documentación de MDN lo define como una función de seguridad que permite al navegador verificar que los recursos que descarga llegan sin manipulación inesperada, comparándolos con un resumen criptográfico que tú declaras por adelantado.
Sin ese resumen, la relación con el proveedor externo es de confianza pura: aceptas lo que su servidor te devuelva, hoy y cualquier otro día. Con él, el navegador comprueba el contenido antes de ejecutarlo y se planta si no es exactamente el que esperabas. Wakaris marca este hallazgo con severidad Importante.
Cómo se comprueba
Wakaris recorre el HTML de la URL que le indiques, localiza las etiquetas que cargan recursos desde un origen externo y comprueba si cada una declara el atributo integrity. Si encuentra alguna sin él, devuelve el hallazgo con la página analizada y el fragmento de código concreto que lo provoca. Es una comprobación de presencia, no una medida: el resultado es que hay recursos sin verificar, o que no los hay.
Conviene saber sobre qué elementos aplica el estándar, porque no es sobre todos. Según MDN, Subresource Integrity funciona con elementos <script> y con elementos <link> cuyo atributo rel sea stylesheet, preload o modulepreload. Las imágenes, los iframes y los recursos que un script carga por su cuenta más tarde quedan fuera del alcance del atributo.
Hay una segunda condición que sorprende a mucha gente: la especificación del W3C obliga a que las peticiones a otro origen que usen integridad viajen con CORS, así que la etiqueta necesita además crossorigin.
Por qué importa
El riesgo no es teórico y la superficie es enorme. Con datos de HTTP Archive, la documentación de Chrome para desarrolladores cifra en más del 94 % los sitios web que usan recursos de terceros, con una media de unos 21 proveedores distintos por página. Cada uno es un servidor que no controlas ejecutando código en el navegador de quien te visita.
La especificación del W3C explica por qué HTTPS no basta: esos mecanismos autentican solo el servidor, no el contenido, y un atacante con acceso al servidor puede manipular el contenido impunemente. Y añade el criterio que resume la amenaza: que se comprometa un servicio de terceros no debería significar automáticamente que se comprometa cada sitio que incluye sus scripts.
OWASP lo formula desde el otro lado, en su guía de gestión de JavaScript de terceros: el mayor riesgo es que se comprometa el servidor del proveedor y se inyecte código malicioso en la etiqueta original. Quien tenga ese acceso puede leer formularios, robar sesiones o redirigir pagos desde dentro de tu propia página.
Causas comunes
Casi nunca es una decisión consciente: es lo que sale por defecto. Las causas se repiten en cuatro formas.
La primera es copiar y pegar el fragmento de instalación que da el proveedor. Muchos lo publican sin integrity, precisamente porque quieren poder cambiar el archivo cuando les convenga.
La segunda es enlazar a una ruta móvil, del tipo /ultima/libreria.js, en lugar de a una versión fija. Un archivo que cambia por su cuenta no puede tener un resumen fijo, así que el atributo es incompatible con esa forma de enlazar.
La tercera es que el proveedor no admita CORS. Si su servidor no envía las cabeceras necesarias, la etiqueta con integrity y crossorigin hará que el recurso no cargue, y la salida fácil ante una web rota es quitar el atributo en lugar de cambiar de proveedor.
La cuarta son los complementos y las plantillas de los gestores de contenido, que insertan sus propias etiquetas hacia servidores externos sin que nadie las revise ni las cuente.
Cómo solucionarlo
El orden importa, porque no todos los recursos externos merecen el mismo trato. Wakaris te da la lista de etiquetas sin verificar y el fragmento exacto de cada una.
Primero, decide qué recursos siguen haciendo falta: la forma más barata de quitar un riesgo de terceros es dejar de cargar el recurso.
Segundo, fija la versión: cambia las rutas móviles por una versión concreta e inmutable, porque sin eso ningún resumen aguanta.
Tercero, calcula el resumen y añádelo. El estándar admite sha256, sha384 y sha512, y MDN los ordena de más débil a más fuerte en ese mismo orden. Cualquier utilidad de línea de comandos que calcule un resumen SHA-384 en base64 te sirve. Pon el valor en integrity y acompáñalo siempre de crossorigin="anonymous".
Cuarto, aloja en tu propio dominio lo que sea imprescindible. Si la página no funciona sin ese recurso, servirlo tú elimina la dependencia.
Y comprueba el resultado: si el resumen no coincide, el navegador se niega a cargar el recurso y devuelve un error de red. Vuelve a pasar la página por Wakaris para confirmar que el hallazgo desapareció.
Comparación de una etiqueta script sin atributo integrity y la misma etiqueta con integrity y crossorigin declarados
Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris. Tema: Comparación de una etiqueta script sin atributo integrity y la misma etiqueta con integrity y crossorigin declarados. Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía. Formato: 16:9, 1440 píxeles de ancho. Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen. Sin logotipos reales ni marcas de terceros. Sin personas reconocibles. Etiquetas: recursos, terceros, verificar, comparación, etiqueta, script, atributo, integrity
Pregúntale a tu IA
Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.
Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo
Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada. Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Recursos de terceros sin verificar. Mi página carga scripts u hojas de estilo alojados en servidores de otros sin el atributo integrity, que es el resumen criptográfico con el que el navegador comprueba que el archivo descargado es exactamente el que yo esperaba. Referencia: se considera fallo cualquier recurso externo cargado sin ese atributo. Pega aquí el resultado de Wakaris: qué recursos externos te ha marcado, de qué dominios vienen y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir. Reglas que debes seguir en todo momento: 1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya medido. Si no lo sabes, pregúntamelo antes de afirmarlo. 2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde: a) ¿En qué plataforma está tu web? (WordPress, Shopify, web a medida, otra) b) De los recursos externos que te han marcado, ¿sabes cuáles siguen haciendo falta y cuáles se quedaron ahí de una versión anterior? c) ¿Enlazas a una versión concreta del archivo o a una ruta genérica del tipo "última versión"? d) ¿Esos recursos los pone alguien a mano en la plantilla, o los insertan complementos y herramientas instaladas? e) ¿Alguno de ellos es imprescindible para que la página funcione, o son accesorios? f) Si hay que tocar el código de la plantilla, ¿lo harías tú, un técnico interno o una agencia? 3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso. 4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes medir, dilo: tú no ves mi web, razonas sobre lo que yo te cuento. 5. Avísame antes de proponerme cambios de riesgo. Añadir un resumen mal calculado, o ponerlo sin CORS, hace que el navegador bloquee el recurso y puede dejar una parte de la web sin funcionar: conviene probarlo antes en un entorno de prueba. 6. Si necesitas un dato que solo se obtiene analizando la web (qué recursos externos hay realmente, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina. 7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí. 8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/recursos-de-terceros Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Aún no lo he medido y quiero comprobar si mi web tiene este problema
Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho. Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: recursos de terceros cargados sin verificar. Consiste en que mi web carga scripts u hojas de estilo desde servidores de otros sin el atributo integrity, el resumen criptográfico con el que el navegador comprueba que el archivo no ha sido alterado. Todavía NO sé si mi web lo tiene: quiero averiguarlo. Reglas que debes seguir en todo momento: 1. Lo primero y más importante: esto se comprueba mirando el código de mis páginas, y tú no puedes analizar mi web desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente. 2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema: a) ¿Tu web usa tipografías, iconos, librerías de animación o mapas que vengan de un servidor externo? b) ¿Tienes instalados complementos, plantillas compradas o herramientas de chat, reseñas o publicidad? c) ¿Sabes si alguien revisó alguna vez qué dominios externos carga tu web? d) ¿En qué plataforma está? (WordPress, Shopify, web a medida, otra; o no lo sé) e) ¿Quién mantiene el código de la web hoy: tú, un técnico interno, una agencia o nadie en concreto? 3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico. 4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dará la lista real de recursos externos sin verificar, el fragmento de código concreto y de paso el estado de las otras áreas. 5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo. 6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y cómo solucionarlo en mi caso concreto. 7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme. Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/recursos-de-terceros Para comprobarlo: https://www.wakaris.com/ Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Preguntas frecuentes
¿Qué es exactamente el atributo integrity? +
Es un atributo que se pone en las etiquetas de script y de hoja de estilo y que contiene un resumen criptográfico del archivo que esperas recibir. El navegador calcula el resumen de lo que ha descargado y lo compara: si no coincide, se niega a cargarlo y devuelve un error de red.
¿Sirve de algo si el recurso ya viaja por HTTPS? +
Sí, porque protegen cosas distintas. La especificación del W3C es explícita: HTTPS autentica el servidor, no el contenido. Quien tenga acceso al servidor del proveedor puede cambiar el archivo, y tu navegador lo recibirá por una conexión perfectamente cifrada y lo ejecutará sin objeción alguna.
¿Puedo poner integrity en cualquier recurso externo? +
No. El estándar cubre las etiquetas de script y las de enlace cuyo atributo rel sea stylesheet, preload o modulepreload. Las imágenes, los vídeos, los iframes y lo que un script cargue después por su cuenta quedan fuera, y para esos casos hacen falta otras medidas de protección.
¿Qué pasa si el proveedor actualiza su archivo? +
El resumen deja de coincidir y el navegador bloquea el recurso, así que la funcionalidad que dependa de él dejará de verse. Por eso conviene enlazar siempre a una versión fija y no a una ruta genérica que el proveedor pueda cambiar sin avisarte de nada.
Fuentes citadas
- developer.mozilla.orgSubresource Integrity, MDN: definición del mecanismo, elementos admitidos, algoritmos sha256/sha384/sha512 y obligación de CORS.
- w3.orgSubresource Integrity, W3C: HTTPS autentica el servidor y no el contenido; el compromiso de un tercero no debería comprometer a cada sitio que lo incluye.
- developer.chrome.comCan browsers optimize the loading of third-party resources?, Chrome for Developers: más del 94 % de sitios usan terceros y una media de 21 proveedores por página, con datos de HTTP Archive.
- cheatsheetseries.owasp.orgThird Party JavaScript Management Cheat Sheet, OWASP: el mayor riesgo es el compromiso del servidor del proveedor y la inyección de código en la etiqueta original.
Actualizado: 7 de septiembre de 2026.
Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.