Qu'est-ce que Subresource Integrity (SRI) ? Guide pour les sites WordPress

Subresource Integrity (SRI) est un standard de sécurité W3C qui vous permet de spécifier un hash cryptographique sur les balises <script> et <link> afin que le navigateur puisse vérifier que le fichier chargé correspond à ce que vous attendez. Si le fichier à l'URL a été modifié, intercepté ou remplacé (que ce soit par un attaquant, un CDN compromis, ou même une mise à jour accidentelle), le navigateur bloque entièrement l'exécution. SRI a été standardisé en 2016 et est supporté par tous les principaux navigateurs. C'est l'une des mesures les moins chères pour atténuer les attaques de la chaîne d'approvisionnement sur du JavaScript tiers, qui est la source dominante des incidents de sécurité sur les sites WordPress en 2026.

À quoi ressemble un hash SRI, et comment l'ajouter ?

Une balise script avec SRI activé a deux attributs supplémentaires : integrity et crossorigin :

<script
  src="https://cdn.example.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous">
</script>

La valeur integrity est un hash cryptographique encodé en base64 du contenu du fichier, préfixé par l'algorithme utilisé (sha256-, sha384- ou sha512-). SHA-384 est le choix recommandé en 2026 : un bon équilibre entre sécurité et longueur de hash. SHA-512 est également acceptable. SHA-256 fonctionne toujours mais est considéré comme le plus faible des trois ; convient pour les ressources non critiques mais pas pour quoi que ce soit de sensible en sécurité.

Quand le navigateur charge le fichier, il calcule son hash et le compare à la valeur integrity. Si les hashes correspondent, le script s'exécute. S'ils diffèrent ne serait-ce que d'un octet, le navigateur refuse de l'exécuter et journalise une erreur dans la console.

Quelles attaques Subresource Integrity prévient-il ?

SRI protège spécifiquement contre le cas où un fichier tiers est modifié entre le moment où vous avez décidé de lui faire confiance et le moment où le navigateur d'un utilisateur le charge réellement. Les trois scénarios les plus pertinents pour les sites WordPress :

• Compromission de CDN. Si un attaquant pénètre dans un CDN (ou dans le service tiers dont vous utilisez le CDN) et modifie un fichier JavaScript, chaque site embarquant ce fichier via <script src> exécuterait soudainement le code de l'attaquant. SRI attrape ça immédiatement : le fichier modifié ne correspond pas au hash, le navigateur le bloque.
• Prise de contrôle de compte chez le fournisseur tiers. Quelqu'un compromet un compte analytics, widget de chat ou hébergement de polices et publie une mise à jour malveillante sur le script que vous avez embarqué. Sans SRI, votre site exécute la mise à jour malveillante à chaque chargement de page. Avec SRI, le script échoue silencieusement jusqu'à ce que vous mettiez à jour le hash, ce qui signifie jusqu'à ce que vous ayez personnellement re-vérifié la nouvelle version.
• Altération au niveau réseau. Un attaquant man-in-the-middle sur un réseau d'entreprise ou un WiFi hostile réécrit un fichier JavaScript pendant qu'il transite vers l'utilisateur. HTTPS empêche cela pour les connexions directes vers votre origine, mais un script tiers servi via une tentative d'empoisonnement DNS contrôlée par l'attaquant pourrait contourner cela. SRI fournit une vérification d'intégrité de bout en bout indépendante de TLS.

La fuite de British Airways en 2018 où 380 000 clients ont eu leurs données de paiement volées s'est produite parce que l'attaquant a modifié un script Modernizr tiers que BA chargeait sur sa page de checkout. SRI sur cette balise script aurait arrêté l'attaque au moment où le fichier modifié s'est chargé. Des incidents similaires continuent de se produire, avec les attaques de type Magecart sur les sites e-commerce comme catégorie la plus documentée.

Sur quels fichiers devrais-je ajouter SRI ?

SRI est pour les fichiers tiers chargés via le réseau. Trois catégories comptent, par ordre de priorité :

• Flux de paiement, checkout et connexion. Tout JavaScript qui s'exécute sur une page où les utilisateurs entrent des cartes bancaires, des mots de passe ou d'autres données sensibles est la cible de plus haute priorité. Un script compromis sur une page de checkout est le pire scénario. Si votre checkout WooCommerce charge quoi que ce soit depuis un CDN, chacun de ces scripts devrait avoir SRI.
• Scripts embarqués globalement. Tout ce qui est dans <head> ou près du début de <body> qui s'exécute sur chaque page : balises analytics, polices, polyfills, jQuery depuis un CDN public. Ceux-ci s'exécutent avant que l'utilisateur ait l'occasion de remarquer quoi que ce soit d'anormal.
• Scripts CDN injectés par plugin. Beaucoup de plugins WordPress (widgets de chat, tests A/B, pixels marketing) chargent du JavaScript distant. Ceux-ci sont écrits par des tiers à qui vous avez implicitement fait confiance, et ils n'incluent typiquement pas SRI par défaut.

À l'inverse, n'ajoutez pas SRI aux fichiers servis depuis votre propre domaine. Si un attaquant a accès pour modifier les fichiers sur votre serveur d'origine, il peut aussi modifier le HTML qui déclare le hash, donc SRI n'apporte aucune protection réelle. SRI brille uniquement pour les ressources cross-origin.

Comment générer un hash SRI pour un script tiers ?

Trois méthodes pratiques :

1. Utiliser srihash.org. Outil web. Collez l'URL du script, récupérez la balise <script> complète avec les attributs integrity et crossorigin. Le chemin le plus rapide pour les ajouts ponctuels.
2. OpenSSL en ligne de commande. curl -s https://cdn.example.com/file.js | openssl dgst -sha384 -binary | openssl base64 -A sort le hash base64 que vous préfixez avec sha384-. Utile pour les scripts ou le travail avec des fichiers localement avant déploiement.
3. Vérifier la documentation du fournisseur. Les principaux CDN (cdnjs.com, jsDelivr) publient le hash SRI à côté de chaque version de chaque bibliothèque qu'ils hébergent. Bootstrap, jQuery, Vue, React, etc. publient tous la valeur integrity recommandée sur leurs pages officielles de démarrage. Copier-coller depuis là.

Une mise en garde : le hash est lié au contenu exact en octets du fichier. Si le CDN sert une version différente (parce que vous avez utilisé une URL comme jquery@3 au lieu de jquery@3.7.1), le hash ne correspondra pas et le script se bloquera. Épinglez toujours sur des versions spécifiques lors de l'utilisation de SRI.

Pourquoi l'attribut crossorigin="anonymous" est-il requis ?

L'attribut crossorigin="anonymous" indique au navigateur de récupérer le fichier tiers en utilisant CORS, sans envoyer de cookies ni d'authentification. Sans lui, le navigateur ne peut pas lire le corps de réponse du fichier pour calculer son hash (un détail de la politique same-origin), et la vérification SRI échoue silencieusement en ouvert : le script s'exécute sans être vérifié.

C'est l'erreur SRI la plus courante. Les gens ajoutent integrity mais oublient crossorigin, puis supposent que leur configuration fonctionne parce que le script continue de charger. Sans les deux attributs, vous n'avez aucune protection réelle. Pour vérifier : ouvrez les DevTools, onglet Network, cliquez sur le script, regardez la réponse. Si le CDN supporte CORS (essentiellement tous les CDN publics modernes le font), vous verrez Access-Control-Allow-Origin: * dans les en-têtes de réponse. Sans cet en-tête, SRI ne peut pas fonctionner du tout sur cette ressource.

Comment ajouter SRI à WordPress ?

Trois scénarios selon la façon dont les scripts arrivent dans vos pages :

Scénario 1 : scripts enqueués par WordPress (thème ou plugin)

Le cœur de WordPress supporte SRI via le filtre script_loader_tag. Ajoutez au functions.php de votre thème enfant ou à un petit mu-plugin :

add_filter('script_loader_tag', function ($tag, $handle, $src) {
    $sri_hashes = [
        'jquery'    => 'sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs',
        'bootstrap' => 'sha384-...votre-hash-ici...',
    ];

    if (isset($sri_hashes[$handle]) && strpos($src, '://') !== false && strpos($src, home_url()) === false) {
        $tag = str_replace(
            ' src=',
            ' integrity="' . $sri_hashes[$handle] . '" crossorigin="anonymous" src=',
            $tag
        );
    }
    return $tag;
}, 10, 3);

Ajustez les noms de handle et les hashes pour correspondre à vos scripts. Les vérifications strpos garantissent que SRI n'est appliqué qu'aux scripts chargés depuis des domaines externes, pas les vôtres.

Scénario 2 : scripts codés en dur dans les templates du thème

Si un thème émet directement des balises <script src="https://..."> dans header.php ou ailleurs, éditez ces balises directement pour ajouter les attributs integrity et crossorigin. Reflétez cela dans votre thème enfant pour survivre aux mises à jour du thème parent.

Scénario 3 : scripts injectés par JavaScript ou plugins tiers à l'exécution

Les widgets de chat, outils de tests A/B et tag managers injectent souvent des balises script dynamiquement. SRI fonctionne toujours dans ce cas : l'élément <script> créé dynamiquement doit définir les propriétés integrity et crossOrigin avant que le script soit ajouté au DOM. La plupart des versions entreprise de ces outils le supportent via la configuration ; les tiers gratuits typiquement non. Pour les injections tierces non gérées, le repli pratique est une Content Security Policy avec require-sri-for script (encore en brouillon) ou simplement un audit attentif.

Quelle est la charge de maintenance de SRI ?

C'est le compromis honnête. SRI est un compromis entre sécurité et commodité. À chaque fois que la bibliothèque amont se met à jour, le hash change, votre script casse, et vous devez mettre à jour le hash. Pour un site stable qui épingle les versions et les met rarement à jour, c'est une tâche trimestrielle. Pour un site qui utilise jquery@latest ou dépend de CDN à mise à jour automatique, SRI est une source constante de cassures.

Trois patterns qui rendent la maintenance SRI gérable :

• Épingler des versions spécifiques, pas "latest". URL comme https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js, pas jquery@latest. Le hash est alors stable jusqu'à ce que vous mettiez délibérément à niveau.
• Utiliser un CDN qui publie des hashes. cdnjs et jsDelivr publient tous deux le hash SRI pour chaque fichier. Mettre à jour le hash quand vous mettez à niveau est une tâche de 30 secondes.
• Auto-héberger les bibliothèques critiques. Une fois auto-hébergé (ce que vous devriez envisager pour des raisons RGPD de toute façon, voir la discussion sur Google Fonts), SRI devient non pertinent pour ce script. SRI est pour les cas où vous ne pouvez pas auto-héberger. Pour analytics, polices, bibliothèques utilisées sur une page, l'auto-hébergement est souvent la meilleure réponse.

Erreurs courantes

• Oublier crossorigin="anonymous". Le script continue de charger mais n'est plus vérifié en intégrité. La défaillance SRI silencieuse la plus courante.
• Utiliser SRI sur des ressources same-origin. Un attaquant qui peut modifier votre /wp-includes/js/jquery.js peut aussi modifier le HTML qui déclare le hash. Utilisez SRI uniquement sur les ressources cross-origin.
• Calculer le hash sur la mauvaise version du fichier. Le hash doit correspondre aux octets exacts que le navigateur recevra, y compris toute minification ou transformation côté CDN. Récupérez toujours depuis l'URL de production réelle lors du calcul.
• Ne pas mettre à jour le hash lors d'une mise à niveau de bibliothèque. Mettre à niveau la version de la bibliothèque dans l'URL, oublier de mettre à jour integrity, le script cesse silencieusement de fonctionner. Symptômes : une fonctionnalité casse, la console montre "Failed to find a valid digest in the integrity attribute".
• Utiliser SHA-1. SHA-1 est vulnérable aux collisions et a été déprécié pour SRI. Utilisez SHA-384 ou SHA-512.
• Essayer d'utiliser SRI sur un CDN sans CORS. Le navigateur ne peut pas calculer le hash, donc SRI est impossible. Soit le CDN doit activer CORS, soit vous devez auto-héberger le fichier.

SRI et Content Security Policy (CSP)

SRI et CSP sont complémentaires, pas redondants. CSP dit "seuls les scripts de cette liste d'origines sont autorisés à s'exécuter". SRI dit "et ce script doit correspondre à ce hash exact". Ensemble, ils forment une approche de défense en profondeur : CSP bloque les origines inconnues ; SRI bloque l'altération des origines connues. Une CSP avec script-src 'self' https://trusted-cdn.com dit "nous faisons confiance à trusted-cdn.com" ; ajouter des hashes SRI à vos scripts sur trusted-cdn.com réduit cette confiance à des versions de fichier spécifiques.

La directive CSP en brouillon require-sri-for script imposerait que chaque script cross-origin doit avoir un attribut integrity, au niveau du navigateur. En 2026, elle a un support limité mais c'est la direction vers laquelle le standard se dirige.

Ce que vérifie InspectWP

La section Sécurité de chaque rapport InspectWP inspecte les balises script et stylesheet externes et signale lesquelles incluent des attributs integrity et lesquelles n'en ont pas. Un SRI manquant sur un script depuis un CDN tiers est signalé comme un constat de sévérité faible à moyenne, selon le contexte. Une page de connexion ou de checkout chargeant du JavaScript externe sans SRI est un avertissement de plus haute priorité. Le rapport signale aussi les valeurs integrity mal formées (mauvais préfixe d'algorithme, base64 invalide) qui peuvent donner un faux sentiment de protection tout en étant en fait ignorées par le navigateur. SRI est l'une de ces mesures où l'existence de l'attribut compte moins que sa correction ; un mauvais hash est fonctionnellement équivalent à pas de hash parce que le navigateur rejette toujours les non-correspondances, mais un attribut crossorigin manquant rend toute la vérification silencieuse.