Résumé

  • Le premier projet public de Subresource Integrity, daté du 18 mars 2014, proposait de comparer des ressources chargées à une empreinte cryptographique. Son éventail d'éléments envisagés dépassait celui de la recommandation finale.
  • La recommandation du W3C du 23 juin 2016 a établi l'attribut integrity pour les scripts et les liens vers des feuilles de style. Face à une réponse admissible, le navigateur calcule l'empreinte et refuse d'exécuter ou d'afficher un fichier qui ne correspond pas.

Le livreur connaissait l'adresse de la fête. Il y venait tous les jours, à l'heure, avec une boîte marquée du nom familier du script. Mais la page avait intérêt à regarder le contenu du colis. Un JavaScript modifié peut changer son comportement; une feuille de style modifiée peut bouleverser ce que voit le lecteur. L'URL indique où chercher. L'empreinte dit quelle version l'hôte avait commandée.

Le premier projet public du W3C, publié le 18 mars 2014, partait de cette différence entre adresse et contenu. Il décrivait une vérification par condensat cryptographique et envisageait une large gamme d'éléments, dont les images et les cadres en plus des scripts et des styles. Le chantier était vaste. Les versions suivantes ont resserré la porte à laquelle le contrôle serait appliqué.

Dans le projet de recommandation candidate du 12 novembre 2015, l'attribut integrity visait les éléments script et link des feuilles de style. La recommandation du 23 juin 2016 a conservé ces deux cas. L'auteur place des métadonnées de hachage à côté de l'URL dans le document. Le navigateur charge le fichier, calcule le condensat de la réponse qui peut être contrôlée, puis le compare à la valeur attendue. Le contenu reçu passe l'examen, pas simplement l'adresse inscrite sur le carton.

Les métadonnées nomment l'algorithme de hachage et le condensat attendu. La recommandation exige la prise en charge de SHA-256, SHA-384 et SHA-512 par les agents utilisateurs. Elle prévoit aussi plusieurs valeurs d'intégrité pour une même ressource et donne priorité à l'algorithme pris en charge le plus robuste. Une page pouvait ainsi exprimer, au point même où elle importe un fichier actif, la version qu'elle était prête à accueillir.

Le contrôle dépend également du type de réponse. Une réponse de même origine peut être examinée; une réponse d'une autre origine le peut si CORS rend son contenu accessible. Une réponse opaque ne livre pas ses octets à cette comparaison. L'éditeur devait donc préparer une empreinte attendue et une récupération que le navigateur pouvait effectivement vérifier. L'empreinte travaille avec les règles de chargement du Web, dans une chaîne concrète de décisions.

Si les condensats diffèrent, la recommandation de 2016 demande au navigateur de refuser l'exécution du script ou l'affichage de la feuille de style et de renvoyer une erreur réseau. Un événement d'erreur donne à l'auteur la possibilité de fournir une solution de repli, par exemple une copie connue sur son propre site. Le livreur n'entre pas avec le mauvais colis. L'éditeur peut ensuite décider comment poursuivre le service au lecteur.

L'historique de publication du W3C relie le premier projet de 2014, l'étape candidate de 2015 et la recommandation de 2016. L'annonce du 23 juin 2016 présente le mécanisme comme un moyen de vérifier qu'une ressource reçue n'a pas subi de modification inattendue. Ce parcours explique aussi le changement d'échelle : la liste expérimentale de 2014 a cédé la place à un contrôle précis des scripts et des feuilles de style.

Reste la tâche quotidienne de l'éditeur. Lorsqu'il change volontairement le fichier, il doit publier l'empreinte correspondant à la nouvelle version. Sinon, le navigateur arrêtera la mise à jour prévue avec la même rigueur qu'une modification surprise. L'auteur décide quel colis est attendu; le navigateur le mesure. Une URL mène le livreur à la porte. L'empreinte permet de savoir s'il apporte bien la commande.