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 garde le contenu d'un fichier, l'autre décide quel code inline peut s'exécuter.

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. Une correspondance exécute le fichier. Un écart est traité comme une erreur réseau, donc 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éactiver tout le script inline.

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 vit	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 se tient entre apostrophes dans un header, un hash SRI se tient dans un attribut HTML et ne porte pas de 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. Faites-les tourner ensemble : CSP pour quel code est autorisé, SRI pour savoir si le fichier autorisé est intact. La directive script-src est l'endroit où se câble la moitié 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 vaut d'être connue que pour ne pas s'en servir.

require-sri-for a été retirée de la spécification CSP. Elle n'a jamais été livrée dans un navigateur stable, Chrome ne l'a jamais implémentée, et Firefox a retiré son implémentation derrière 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, le évaluateur CSP décompose une politique directive par directive et signale les points faibles.

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