Integridad de subrecursos para scripts y hojas de estilo de terceros

Qué es

MDN (citado) describe la integridad de subrecursos como una defensa contra un host de terceros comprometido: el atributo integrity contiene uno o más hashes, cada uno con el prefijo sha256-, sha384- o sha512-, y antes de ejecutar un script o aplicar una hoja de estilo, el navegador calcula el hash del contenido obtenido y lo compara. Usa solo el algoritmo más fuerte presente, acepta una coincidencia con cualquier valor listado para ese algoritmo, y ante una discrepancia rechaza el recurso con un error de red. Se aplica a <script> y a <link> con rel de stylesheet, preload o modulepreload. La especificación del W3C (citada) indica que la integridad de subrecursos requiere CORS: un recurso de origen cruzado debe solicitarse con el atributo crossorigin y el servidor debe responder con Access-Control-Allow-Origin, de lo contrario la comprobación no puede realizarse.

Por qué importa

Una página que carga https://cdn.example/lib.js ejecuta lo que sea que ese host sirva, hoy y después de que el host se vea comprometido, se venda o sea secuestrado mediante DNS. Un hash convierte «confiar en el host» en «confiar en este archivo exacto», la misma disciplina que fijar una dependencia por digest.

Cómo aplicarlo

• Calcular el hash a partir de los bytes exactos que se probaron: cat lib.js | openssl dgst -sha384 -binary | openssl base64 -A (según MDN), o tomar el valor que emite el empaquetador.
• Fijar solo URL versionadas (/lib@1.2.3/lib.min.js); una URL «latest» fallará en cuanto el proveedor la actualice, que es justo la función funcionando.
• Añadir crossorigin="anonymous" a todo elemento de origen cruzado con integrity; sin él, el navegador no cargará el recurso en absoluto.
• Tratar una actualización de hash como una actualización de dependencia: obtener el archivo nuevo, revisar el diff o el registro de cambios, recalcular, hacer commit.
• Vigilar el rastreador de errores por si el recurso fijado no llega a cargar (un script que nunca define su global); una oleada repentina significa que el proveedor cambió el archivo o que alguien lo manipuló.
• Combinar con una Content Security Policy que restrinja los orígenes de los scripts; SRI verifica el contenido, CSP verifica el origen.

Trampas

Los recursos que legítimamente varían en cada solicitud (gestores de etiquetas, scripts de A/B, paquetes personalizados) no se pueden fijar; hay que alojar una copia propia fija o aceptar la confianza. Calcular el hash de un archivo minificado después de un pipeline que vuelve a minificarlo. Olvidar que un script que el script fijado carga en tiempo de ejecución no queda cubierto. Un CDN sin encabezados CORS, lo que hace fallar toda carga fijada.