SaaSFort Subresource Integrity existe depuis une décennie. Vous ajoutez une empreinte à une balise de script, le navigateur vérifie que le fichier correspond avant de l’exécuter, et un CDN compromis ne peut plus vous servir de code modifié.
Cela fonctionne. Cela comporte aussi un défaut structurel qui n’a rien à voir avec la cryptographie : le mécanisme est facultatif, balise par balise.
Comment la couverture SRI se dégrade
Une équipe audite ses scripts tiers, ajoute des attributs integrity à tous, et passe le contrôle.
Six mois plus tard, il y a un nouveau prestataire d’analytics, un widget de support ajouté par l’équipe marketing, et un extrait d’A/B testing collé depuis un tableau de bord. Aucun ne porte d’attribut d’intégrité, parce que rien ne l’exigeait.
Votre couverture SRI est désormais partielle, et une couverture partielle ne protège rien : un attaquant compromettant le CDN n’a besoin que d’un seul script non protégé.
C’est l’issue normale, pas un manque de rigueur. Tout contrôle qui repose sur le fait que chaque développeur futur s’en souvienne finira par se dégrader.
Ce que fait Integrity-Policy
Integrity-Policy est un en-tête de réponse issu de SRI niveau 2 qui déplace l’exigence de la balise vers la page. Une fois posé, le navigateur bloque toute requête vers la destination indiquée qui arrive sans métadonnées d’intégrité.
Integrity-Policy: blocked-destinations=(script), endpoints=(integrity-endpoint)
Reporting-Endpoints: integrity-endpoint="https://votredomaine.fr/_reports/integrity"
Le nouveau script que quelqu’un ajoutera le trimestre prochain sans attribut integrity ne s’exécute pas. Il ne fonctionne pas à moitié et n’échoue pas silencieusement d’une manière que personne ne remarque : il est bloqué, et un rapport est émis.
L’en-tête bloque également d’emblée les requêtes en mode no-cors, fermant la voie où un script est récupéré dans un mode qui rend la vérification d’intégrité impossible.
Le piège qui vous attend
Il n’existe aucun moyen de distinguer les ressources de première partie des ressources tierces dans Integrity-Policy.
Si vous l’activez, chaque script a besoin d’un attribut d’intégrité, y compris vos propres bundles. Pour un site dont la sortie de build est nommée par empreinte, c’est une étape de build. Pour un site qui sert /app.js et l’écrase à chaque déploiement, c’est un vrai changement de chaîne de production, car l’empreinte dans le HTML doit être régénérée avec le bundle.
C’est intentionnel. L’en-tête provient d’un effort visant à apporter au web une signature de code comparable à celle des magasins d’applications, où la garantie est que rien sur la page n’a été altéré, et pas seulement que les parties tierces ne l’ont pas été.
Anticipez-le. L’outillage de build de la plupart des frameworks émet des empreintes SRI via une option ou un petit greffon, mais c’est un changement à décider délibérément plutôt qu’à découvrir en production.
Support navigateur en 2026
| Navigateur | État |
|---|---|
| Chromium | Livré depuis Chrome 130 |
| Firefox | Partiel depuis Firefox 145, destination script uniquement |
| Safari | Pas encore |
Une couverture partielle vaut tout de même le déploiement. L’en-tête est ignoré là où il n’est pas pris en charge, donc aucun risque de compatibilité, et la majorité du trafic obtient l’application.
Déployez d’abord en report-only
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)
En mode report-only, le navigateur autorise la requête en infraction et la signale. C’est la première étape sûre, et elle produit tôt ce que vous voulez vraiment : la liste complète de chaque script actuellement servi sans métadonnées d’intégrité, recueillie sur de vrais chargements de page plutôt que par exploration.
Ramenez cette liste à zéro, puis basculez l’en-tête en mode application.
Vous pouvez aussi observer les violations en JavaScript avec un ReportingObserver enregistré pour integrity-violation, ce qui est utile pendant la migration.
Pourquoi cela a sa place dans une réponse fournisseur
La compromission de la chaîne d’approvisionnement via un script tiers est l’une des rares attaques qui contourne à peu près tous les contrôles sur lesquels un éditeur SaaS est habituellement interrogé. Le code est servi depuis une origine autorisée, en TLS, à un utilisateur authentifié, dans une page dotée d’une CSP valide. La CSP ne défend explicitement pas contre cela : elle vérifie d’où vient un script, pas ce qu’il contient.
Les équipes sécurité côté entreprise ont commencé à poser la question directement, généralement formulée « comment détectez-vous la modification de code tiers dans votre application ». « Nous épinglons des empreintes d’intégrité et les faisons appliquer par le navigateur via Integrity-Policy » est une réponse nettement meilleure que « nous évaluons nos prestataires ».
Elle complète, sans le remplacer, un SBOM : le SBOM dit de quoi vous dépendez, la politique d’intégrité garantit que ce qui est livré est bien ce que vous avez approuvé.
Où cela se mappe en conformité
- NIS2 article 21(2)(d), sécurité de la chaîne d’approvisionnement, et 21(2)(g), hygiène informatique de base.
- ISO/IEC 27001:2022 A.5.21 (gestion de la chaîne d’approvisionnement TIC) et A.8.28 (développement sécurisé).
- DORA article 28, risque lié aux tiers TIC, ainsi que l’article 6.
Comment le vérifier
curl -sI https://votredomaine.fr | grep -i "integrity-policy"
Un scan SaaSFort distingue trois états, car ils ont des significations opérationnelles différentes : appliqué, report-only, et absent. Le report-only est un progrès, pas une protection.
En résumé
SRI est une promesse balise par balise qui se dégrade. Integrity-Policy est une règle au niveau de la page qui ne se dégrade pas.
Commencez par Integrity-Policy-Report-Only, servez-vous des rapports comme inventaire, puis appliquez.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.