Resumen

  • El primer borrador público de Subresource Integrity salió el 18 de marzo de 2014 y propuso comprobar recursos descargados mediante resúmenes criptográficos. La lista inicial de elementos considerados era más amplia que la de la Recomendación posterior.
  • La Recomendación del W3C del 23 de junio de 2016 especificó el atributo integrity para scripts y enlaces a hojas de estilo. El navegador compara una respuesta apta para la comprobación y rechaza el archivo cuando su resumen no coincide.

El repartidor conocía la dirección. Había llevado el script a la página muchas veces, siempre con el mismo nombre en la caja. Aun así, lo que importaba estaba dentro. Un JavaScript diferente puede cambiar lo que hace el sitio; una hoja de estilo diferente puede cambiar lo que ve el lector. La URL sirve para encontrar al repartidor. La huella criptográfica permite reconocer la versión que el editor esperaba recibir.

El primer borrador público del W3C, publicado el 18 de marzo de 2014, planteó el control de integridad como una comparación entre el recurso obtenido y un resumen previamente indicado. Aquella propuesta estudiaba muchos tipos de elementos, incluidas imágenes y marcos además de scripts y estilos. Era una mesa de trabajo con más herramientas de las que acabarían dentro de la norma terminada.

En el documento de Recomendación Candidata del 12 de noviembre de 2015, el atributo integrity ya se centraba en script y en link cuando enlaza una hoja de estilo. La Recomendación del 23 de junio de 2016 mantuvo ese ámbito. El editor podía colocar los metadatos de integridad junto a la URL en el HTML. El navegador obtenía el recurso, calculaba el resumen de una respuesta verificable y lo comparaba con el valor esperado. La inspección correspondía al contenido entregado.

Los metadatos incluyen el nombre de una función de resumen y el resultado esperado. La Recomendación exigió que los navegadores admitieran SHA-256, SHA-384 y SHA-512 para este uso. También permitió indicar varios valores para un recurso y dar prioridad al algoritmo admitido más robusto. La página expresaba así qué edición del archivo aceptaba exactamente en la frontera donde un fichero externo se convertiría en código o presentación.

La respuesta debía dejarse inspeccionar. El documento de 2016 permite comprobar recursos del mismo origen y recursos de otro origen accesibles mediante CORS. Una respuesta opaca no expone los datos necesarios para calcular y comparar el resumen. El editor tenía que preparar tanto la huella como un modo de entrega que el navegador pudiera verificar. La comprobación encaja en las reglas de carga del navegador, con pasos precisos.

Si los valores no coinciden, la Recomendación de 2016 ordena rechazar la ejecución o representación del recurso y devolver un error de red. Se dispara un evento de error que el autor puede usar para cargar una alternativa conocida, como una copia propia. Al visitante de la dirección correcta se le detiene por traer el paquete equivocado. El sitio decide entonces cómo seguir prestando servicio al lector.

El historial de publicación del W3C une el borrador inicial de 2014 con la fase candidata de 2015 y la Recomendación de 2016. El anuncio del 23 de junio de 2016 resumió el objetivo: verificar que un recurso recuperado llega sin una manipulación inesperada. La trayectoria muestra también el recorte del ámbito: de una lista temprana de posibilidades a la comprobación de scripts y enlaces de estilo.

La nueva regla tenía una consecuencia para el trabajo diario. Al actualizar deliberadamente el archivo, el editor debe cambiar también el resumen esperado. Un valor viejo detendrá una actualización legítima con la misma firmeza que detiene un cambio imprevisto. El autor escribe qué versión invita; el navegador hace la comparación. La URL llevó el paquete hasta la puerta. La huella decidió si era el paquete encargado.