Comment corriger un constat Unsafe Implementation of Subresource Integrity
CentralCSP Team ·
Dernière mise à jour:
SecurityScorecard a scanné votre site et ouvert un constat nommé "Unsafe Implementation of Subresource Integrity (SRI)" sous son facteur Application Security, classé en gravité élevée (clé du problème unsafe_sri_v2). Cela signifie que le scanner a trouvé des scripts chargés depuis des hôtes externes sans attribut integrity correct (et souvent sans le crossorigin qui l'accompagne), donc le navigateur prend ces fichiers pour argent comptant. La correction n'est pas compliquée, c'est juste un workflow : trouver quels scripts n'ont pas de SRI, générer les bons hashes, et déployer le changement sans risque pour ne pas casser la page.
En résumé : listez chaque script externe et vérifiez lesquels n'ont pas de paire integrity/crossorigin valide, générez le hash de chacun, ajoutez-le, et vérifiez en mode report-only avant de vous y fier. Cet article parcourt ce workflow de bout en bout.
Ce que le constat signifie réellement
Subresource Integrity (SRI) permet au navigateur de vérifier qu'un script qu'il a récupéré correspond à un hash que vous avez fourni, et de le refuser en cas de non-correspondance. SecurityScorecard signale l'absence de cette protection : un <script src> pointant vers un CDN ou un hôte tiers sans attribut integrity, ou un avec integrity mais sans crossorigin (ce qui échoue silencieusement pour les fichiers cross-origin).
Un point à clarifier, parce qu'il fait trébucher : ajouter une politique de sécurité du contenu n'efface pas ce constat. Seul l'ajout d'un attribut integrity, avec crossorigin, à chaque balise de script ou de style concernée, ou le fait de self-héberger la ressource pour qu'elle soit servie same-origin, le résout. Une CSP contrôle quelles origines peuvent charger, pas si un fichier chargé a été altéré, c'est donc le mauvais outil pour ce constat précis.
Le risque sous-jacent est réel dans les deux cas. Si l'hôte tiers est compromis et sert du code altéré, un script non hashé exécute le fichier trafiqué sans broncher. C'est le scénario de formjacking et de supply-chain que le SRI existe pour arrêter.
1. Trouvez les scripts qui n'ont pas d'integrity
Vous ne pouvez pas hasher ce que vous n'avez pas inventorié. Commencez par lister chaque script externe que la page charge et par marquer ceux qui n'ont pas de paire integrity/crossorigin correcte.
Un scan rapide avec le scanner de security headers montre la posture des headers de la page, et l'inventaire de scripts construit la liste complète des scripts qui s'exécutent sur vos pages à partir des rapports de hash CSP, y compris les tiers qu'un scan d'une seule page manque. Si vous avez une Integrity-Policy en mode report-only, ses rapports integrity-violation nomment directement chaque script sans SRI valide, ce qui est la liste précise dont vous avez besoin.
Attention au piège du cross-origin pendant l'audit : un script peut avoir un attribut integrity et rester non protégé si crossorigin manque, parce que le navigateur ne peut pas lire les octets pour les vérifier.
<script
src="https://cdn.example.com/widget.js"></script>
<script
src="https://cdn.example.com/widget.js"
integrity="sha384-<digest>"
crossorigin="anonymous"></script> 
2. Générez le hash de chaque script
Pour chaque script de la liste, générez son hash. Collez l'URL dans le générateur SRI, qui produit la valeur integrity complète (SHA-256, SHA-384 et SHA-512) à partir du fichier exact que sert l'hôte. Utilisez SHA-384 ou SHA-512 ; si vous listez plusieurs algorithmes, le navigateur vérifie avec le plus fort présent.
Épinglez une URL versionnée, pas une URL « latest ». Le SRI ne se met pas à jour automatiquement, donc un hash sur une URL qui pointe toujours vers le build le plus récent cassera dès que le fichier amont change. Épinglez la version, hashez ce fichier exact, et mettez les deux à jour ensemble quand vous montez de version. L'explication du SRI et comment générer un hash SRI couvrent les mécanismes.
3. Déployez d'abord en report-only
Ajouter des hashes est sûr balise par balise, mais si vous voulez aussi appliquer le SRI sur tout le site pour que le constat ne puisse pas revenir, faites-le d'abord en mode report-only. Un header Integrity-Policy-Report-Only signale chaque script qui n'a toujours pas d'integrity valide sans rien bloquer, vous confirmez donc votre couverture avant d'appliquer.
Reporting-Endpoints: integrity-endpoint="https://<Endpoint-ID>.report.centralcsp.com"Integrity-Policy-Report-Only: blocked-destinations=(script), endpoints=(integrity-endpoint)Laissez-le tourner jusqu'à ce que plus aucun script n'apparaisse dans les rapports. Puis retirez le suffixe -Report-Only pour appliquer. Appliquer avant que le rapport soit propre bloquerait des scripts légitimes mais non hashés et mettrait la page à terre, c'est pourquoi le report-only passe en premier.
4. Vérifiez et re-scannez
Une fois les hashes en place et le flux report-only silencieux, re-scannez avec le service de notation (ou le scanner de security headers) pour confirmer que le constat s'efface. Gardez l'inventaire et le reporting actifs ensuite : le constat revient dès que quelqu'un ajoute une nouvelle balise tierce non hashée, et un inventaire de scripts continu capte ce changement avant que le prochain scan ne le fasse.
CentralCSP maintient cette boucle en marche, inventaire de chaque script, rapports integrity-violation, et alerte quand un script nouveau ou modifié apparaît, pour que le constat reste fermé au lieu de rouvrir au prochain audit. Commencez gratuitement pour inventorier vos scripts et guetter la prochaine faille.