SRI contre hash CSP, deux hashes aux rôles différents

Un hash Subresource Integrity (SRI) et un hash de politique de sécurité du contenu (CSP) commencent tous deux par sha256- ou sha384-, alors on les prend pour la même chose. Ils ne le sont pas. Un hash SRI vérifie les octets d'un fichier externe que vous chargez par URL. Un hash CSP autorise le texte d'un script inline que votre page exécute. Des entrées différentes, des rôles différents, et vous utilisez souvent les deux sur la même page.

La version courte : si vous avez écrit integrity="sha384-..." sur une balise <script src=...>, c'est du SRI, et cela vérifie que le fichier renvoyé par le serveur correspond à votre hash. Si vous avez écrit 'sha256-...' dans script-src, c'est une source hash CSP, et cela vérifie que le contenu d'un bloc <script> inline correspond à votre hash. L'un protège le contenu d'un fichier, l'autre décide quel code inline peut s'exécuter. Aucun des deux ne dit si le fichier est une version vulnérable ; c'est une vérification à part, couverte dans comment détecter les bibliothèques JavaScript vulnérables sur un site en production.

La différence en une phrase

SRI hache un corps de réponse. Un hash CSP hache du texte source inline.

C'est toute la distinction, et tout le reste en découle. SRI demande "ce fichier est-il celui que j'ai épinglé ?" avant d'exécuter une ressource externe. Un hash CSP demande "ce bloc inline est-il un de ceux que j'ai explicitement autorisés ?" avant d'exécuter du code inline. Aucun ne remplace l'autre, parce qu'ils agissent à des moments différents et sur des entrées différentes.

SRI vérifie un fichier externe

SRI est l'attribut integrity que vous posez sur une balise qui charge du code depuis un autre hôte. Le navigateur télécharge le fichier, hache les octets reçus et les compare à votre valeur. S'ils correspondent, le fichier s'exécute. Sinon, le navigateur traite l'écart comme une erreur réseau, et rien ne s'exécute.

<script
  src="https://cdn.example.com/library.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Le hash couvre le corps de réponse exact à cette URL. Si le CDN est compromis et sert du code modifié, les octets ne correspondent plus au hash et le navigateur écarte le fichier. L'attribut crossorigin est obligatoire pour un fichier cross-origin, parce que le navigateur ne peut pas lire les octets d'une réponse opaque. Subresource Integrity (SRI) expliqué couvre cette exigence en détail.

Un hash CSP autorise du code inline

Une source hash CSP est un digest que vous écrivez dans script-src (ou style-src). Une politique de sécurité du contenu bloque les scripts inline par défaut. Une source hash réautorise un bloc inline précis par son contenu, sans réautoriser l'inline dans son ensemble.

Content-Security-Policy: script-src 'self' 'sha256-q1V8...='

Quand le navigateur rencontre un <script> inline, il hache le texte entre les balises et le confronte aux hashes de la directive. Le hash porte sur le contenu inline exact, pas sur un fichier, pas sur la balise, pas sur les attributs. Comment générer un hash CSP (sha256) détaille le calcul et les pièges d'espaces qui le cassent, et la référence hashes et nonces CSP documente le mot-clé.

Côte à côte

Les préfixes sont identiques, les entrées non. Mettez la même chaîne au mauvais endroit et elle ne sert à rien.

	Hash SRI	Source hash CSP
Où il se place	L'attribut `integrity` sur une balise	`script-src` / `style-src` dans la politique
Ce qu'il hache	Les octets de réponse d'un fichier externe	Le texte inline d'un bloc `<script>`
La question qu'il tranche	Ce fichier téléchargé est-il intact ?	Ce bloc inline peut-il s'exécuter ?
Préfixe	`sha256-` / `sha384-` / `sha512-`	`sha256-` / `sha384-` / `sha512-`
À mettre à jour quand	Le fichier externe change	Le code inline change

Un indice pratique : un hash CSP s'écrit entre apostrophes dans un header, un hash SRI s'écrit dans un attribut HTML, sans guillemets autour du préfixe d'algorithme.

Ils se complètent

Ce sont des contrôles orthogonaux, et une page durcie utilise les deux. CSP décide quels scripts peuvent s'exécuter tout court, par origine, par nonce ou par hash. SRI garantit ensuite qu'un fichier externe autorisé n'a pas été modifié depuis que vous l'avez épinglé.

Un script peut passer CSP et être altéré quand même. Disons que votre politique autorise https://cdn.example.com comme source hôte. CSP est satisfaite dès que le script vient de cette origine, elle n'inspecte pas le contenu. Si le CDN sert du code modifié, seul SRI l'attrape, parce que seul SRI hache la réponse. Utilisez les deux : CSP pour dire quel code est autorisé, SRI pour vérifier que le fichier autorisé est intact. C'est dans la directive script-src que se règle la partie CSP.

Et require-sri-for ?

Il a existé une directive CSP censée relier les deux : require-sri-for, qui aurait imposé un attribut integrity sur chaque script ou style. Elle ne mérite d'être connue que pour ne pas s'en servir.

require-sri-for a été retirée de la spécification CSP. Elle n'est jamais arrivée dans un navigateur stable, Chrome ne l'a jamais implémentée, et Firefox a retiré son implémentation, qui restait derrière un flag. Elle n'est pas interopérable et vous ne pouvez pas compter dessus aujourd'hui.

La façon moderne d'exiger l'intégrité sur tout le site est un header séparé, Integrity-Policy. Au lieu d'une directive CSP, il demande au navigateur de bloquer toute sous-ressource concernée qui se charge sans métadonnées d'intégrité, et de la signaler comme integrity-violation.

Integrity-Policy: blocked-destinations=(script)

La destination script est désormais appliquée dans les versions actuelles de Chrome, Firefox et Safari. Une variante report-only, Integrity-Policy-Report-Only, fait remonter les manques sans bloquer, pour mesurer la couverture avant d'appliquer.

Lequel choisir ?

Vous chargez un fichier tiers par URL et voulez épingler son contenu ? C'est SRI, sur la balise. Générez la valeur avec le générateur SRI.
Vous autorisez un bloc <script> inline précis sous une politique stricte ? C'est un hash CSP, dans script-src.
Vous voulez exiger l'intégrité sur tout le document ? Utilisez le header Integrity-Policy, pas require-sri-for.

Si vous auditez une politique existante et ne savez plus quels hashes font quoi, l'évaluateur CSP décompose une politique directive par directive et signale les points faibles.

Savoir quels scripts vous chargez vient avant l'un comme l'autre hash. À partir des rapports de hash CSP, CentralCSP dresse l'inventaire de tout ce qui s'exécute sur vos pages, pour repérer le code tiers nouveau ou modifié avant qu'il ne devienne un incident. Commencez gratuitement pour cartographier vos dépendances côté client.