Integrity-Policy
Integrity-Policy exige que les scripts chargés portent une Subresource Integrity valide, pour bloquer ou signaler une ressource altérée ou remplacée.
Dernière mise à jour:
Integrity-Policy permet à un site d'exiger que chaque ressource d'un type donné porte
des métadonnées Subresource Integrity (SRI) valides. Si un script est chargé sans
valeur integrity correcte, par exemple parce qu'un asset CDN a été remplacé ou
altéré, le navigateur le bloque ou le signale. Elle transforme SRI d'un opt-in par
balise en une politique applicable à tout le site, reprenant l'objectif de la
directive CSP abandonnée
require-sri-for.
Disponibilité limitée
Integrity-Policy est récente mais n'est plus mono-moteur. L'application pour la destination script est désormais livrée dans les trois moteurs (Chrome, Firefox et Safari) ; Firefox ne livre les rapports aux endpoints que dans les versions récentes, et la destination style est derrière une pref Firefox uniquement. Voir Prise en charge des navigateurs plus bas.
Commencez en Report-Only, avec le nom d'endpoint déclaré dans
Reporting-Endpoints :
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)Comment fonctionne Integrity-Policy
Vous déclarez quelles destinations de ressources doivent être protégées par
intégrité. Le navigateur exige alors un attribut integrity valide sur chaque
chargement de ce type et bloque (ou, en Report-Only, signale) tout ce qui en manque.
Au lieu de penser à un attribut integrity sur chaque balise, vous énoncez
l'exigence une seule fois.
Comment configurer Integrity-Policy
Integrity-Policy: blocked-destinations=(script)| Directive | Statut | Signification |
|---|---|---|
blocked-destinations | ✅ Bon | Requise. Les destinations qui doivent être protégées par intégrité. script est multi-navigateurs (Chrome, Firefox et Safari) ; la valeur style est 🧪 Expérimental, derrière une pref Firefox uniquement. |
sources | 🧪 Expérimental | Optionnelle. Où l'intégrité est exigée ; inline (la seule valeur, et le défaut) désigne l'attribut integrity. |
endpoints | ✅ Bon | Optionnelle. Les noms d'endpoints de reporting déclarés dans Reporting-Endpoints. Firefox ne livre les rapports aux endpoints que dans les versions récentes. |
Mode Report-Only
Reporting-Endpoints: integrity-endpoint="https://<Endpoint-ID>.report.centralcsp.com"Ceci déclare le nom integrity-endpoint référencé par l'exemple d'ouverture.
Report-Only liste chaque script dépourvu de SRI valide sans le bloquer, ce qui est la
manière sûre de découvrir ce qui n'est pas encore hashé avant d'appliquer.
Ce contre quoi il protège
L'altération de la chaîne d'approvisionnement : un script CDN modifié ou remplacé, un
asset injecté, ou une ressource chargée en mode no-cors sans protection
d'intégrité. SRI attrape le remplacement parce que le hash ne correspond plus ;
Integrity-Policy rend cette protection obligatoire plutôt que par balise.
Configurations non sûres à éviter
Appliquer avant de savoir quels scripts portent SRI bloquera des scripts légitimes
mais non hashés et cassera la page. Lancez d'abord Report-Only, et ajoutez l'attribut
integrity (ou supprimez la dépendance) pour tout ce qui remonte.
Contournements et limites connus
En pratique limitée aux scripts pour le moment : la destination style existe dans
la spec mais n'est livrée que derrière une pref Firefox. Les versions plus anciennes
de Firefox appliquent la politique mais écrivent dans la console au lieu de livrer des
rapports aux endpoints. Et elle complète plutôt qu'elle ne remplace une CSP solide ;
les deux couvrent des parties différentes du problème de confiance des scripts.
Risques
Un déploiement sans inventaire des scripts qui portent déjà SRI peut faire tomber la page. Construisez d'abord cet inventaire, puis appliquez.
Recommandation
Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)Commencez en Report-Only, le chemin de déploiement que recommande
MDN :
observez quels scripts remontent sans
Subresource Integrity valide, ajoutez les
hashes manquants (le générateur SRI les calcule), puis passez
le header à Integrity-Policy une fois les rapports au calme.
Reporting
Integrity-Policy sélectionne ses endpoints de reporting avec la directive
endpoints=(), pas avec le paramètre report-to= que les autres politiques
utilisent, avec les noms déclarés dans Reporting-Endpoints. Le navigateur émet le
rapport integrity-violation.
Associez-le à l'inventaire de scripts de
CentralCSP et au générateur SRI pour savoir et corriger ce qui
manque d'intégrité.
Prise en charge par les navigateurs
Définie dans la spec SRI ; disponibilité limitée, mais la destination script est
désormais appliquée dans les trois moteurs : Chrome, Firefox et Safari. Firefox ne
livre les rapports aux endpoints que dans les versions récentes (les versions
antérieures écrivaient dans la console). La destination style est derrière une pref
Firefox uniquement.
FAQ
Que fait Integrity-Policy ?
Integrity-Policy permet à un site d'exiger que chaque ressource d'un type donné
porte des métadonnées Subresource Integrity valides. Si un script se charge sans
valeur integrity correcte, parce qu'un asset CDN a été remplacé ou altéré, le
navigateur le bloque ou le signale. Elle transforme SRI d'un opt-in par balise en
une exigence applicable à tout le site.
Quelle est la différence entre Integrity-Policy et Subresource Integrity ?
SRI est un opt-in par balise : vous ajoutez un attribut integrity à chaque balise
de script ou de style que vous voulez vérifier, et le navigateur contrôle le hash
sur cette seule balise. Integrity-Policy applique SRI à tout le site, en exigeant
une valeur integrity valide sur chaque chargement d'une destination déclarée, pour
que rien ne passe sans être hashé.
Voir aussi
- Subresource Integrity (SRI)
- require-sri-for, le prédécesseur CSP retiré
- Integrity-Policy expliqué (guide)
- rapport integrity-violation
- rapport csp-hash
- Header Reporting-Endpoints
- Surveillance Integrity-Policy dans CentralCSP
Sources
Document-Policy
Document-Policy définit des points de configuration par document, comme js-profiling, avec un reporting de violations optionnel.
Network Error Logging
NEL demande au navigateur de signaler les échecs de requêtes au niveau réseau, DNS, TLS, connexion et erreurs HTTP, vers un endpoint que vous contrôlez.