Le terme « intégrité des scripts » est utilisé dans des référentiels de conformité tels que PCI DSS 4.0.1, ISO 27001, HIPAA et d'autres frameworks — mais que signifie-t-il exactement et qu'est-ce qui est attendu ?
Pourquoi l'intégrité des scripts est essentielle pour les marchands et les entreprises e-commerce
Les ressources récupérées depuis des tiers proviennent d'une source externe. Faire confiance inconditionnellement à une source n'est pas sûr dans un environnement internet en constante évolution. Les entreprises SaaS apparaissent et disparaissent, et malheureusement beaucoup n'ont pas de plan de continuité pour les domaines qu'elles utilisaient dans les environnements de production de leurs clients.
De nombreux incidents ont eu lieu par le passé, affectant des consommateurs à travers le monde sans qu'ils en soient conscients.
Les injections via le détournement d'une source tierce peuvent se produire de plusieurs façons.
- Ingénierie sociale
- Détournements ciblant les pipelines CI/CD
- Dépendances open source malveillantes
- Injections de malwares au niveau machine sur les appareils des développeurs
- Récupération d'un domaine expiré
Il n'est pas nécessaire qu'il s'agisse d'une attaque sophistiquée sur la chaîne d'approvisionnement : cela peut commencer par un point d'entrée banal (comme un domaine expiré) qui offre aux attaquants une ouverture discrète pour manipuler le code s'exécutant sur votre site sans que personne ne s'en aperçoive.
La prochaine fois que vos utilisateurs saisissent des informations sur vos pages, des données sensibles peuvent être collectées via des <iframe> malveillants superposés aux éléments de paiement (web skimming), des chaînes de redirections forcées, du détournement de cookies d'affiliation, de la livraison de malwares au niveau de l'appareil, ou même de l'exploitation de failles zero-day dans les navigateurs.
Intégrité des scripts : pour les exigences de conformité
Les référentiels de conformité attendent de plus en plus des entreprises qu'elles surveillent l'intégrité et l'historique des modifications des scripts côté client.
- Pour PCI DSS 4.0.1 : la validation de l'intégrité des scripts est requise pour satisfaire aux exigences de détection des changements des articles 6.4.3 et 11.6.1 (Comment se conformer à PCI DSS 6.4.3 & 11.6.1)
Intégrité des scripts : pour prévenir les attaques côté client
Selon Mastercard, la principale source de skimming de cartes bancaires est l'e-skimming, qui se produit côté client. Les scripts compromis constituent une porte ouverte pour les attaquants afin de mener :
- Du formjacking, des attaques Magecart, du web skimming, des redirections malveillantes à des fins de phishing, et d'autres types d'attaques qui ont touché plus de 380 000 sites web en 2025 (Rapport sur les attaques côté client 2025).
Gestion de l'intégrité des scripts : pour les entreprises e-commerce
Tout marchand traitant un volume élevé de transactions en ligne est une cible privilégiée pour l'exploitation côté client.
- Les sites e-commerce modernes intègrent des dizaines de scripts tiers. Les marchands ont besoin de visibilité sur ce que font ces scripts, quand ils changent, et si ces changements correspondent au comportement attendu.
Qu'est-ce que l'intégrité des scripts ?
Les idées reçues sur le terme
Le terme « intégrité des scripts » est probablement utilisé par amorçage lexical avec la méthode de gestion « Subresource Integrity » référencée dans les principaux référentiels de conformité. L'amorçage lexical consiste à réutiliser des mots que l'on vient de rencontrer — nous le faisons tous.
Cependant, utiliser le mot « intégrité » seul peut prêter à confusion et reste ouvert à l'interprétation.
Qu'est-ce qui qualifie un script comme ayant (ou non) de l'intégrité ?
Surveiller le comportement pour l'intégrité des scripts
L'intégrité dans ce contexte peut signifier : « s'assurer que les scripts ne se comportent pas de manière malveillante ». Le problème est que l'exfiltration de données seule n'est pas un comportement malveillant en soi, pas plus que les redirections. De nombreux scripts tiers font cela pour des raisons légitimes, ce qui rend très difficile le contrôle des modifications.
Surveiller les modifications des scripts pour l'intégrité des scripts
Le facteur de changement est ce à quoi les référentiels de conformité font le plus souvent référence : s'assurer que lorsqu'un script change, ces modifications correspondent à l'usage attendu du script.
Qu'est-ce que la Subresource Integrity (SRI) ?
La Subresource Integrity (SRI) est un outil de sécurité natif des navigateurs qui permet au propriétaire d'un site web d'ajouter un hachage à une directive de script dans une application web. SRI existe depuis 2015, lorsque Google et Mozilla l'ont intégré dans leurs navigateurs, avant d'être reconnu par le w3c en 2016.
Objectif de la Subresource Integrity (SRI)
L'objectif de SRI était d'empêcher les ressources statiques récupérées côté client — comme les ressources versionnées — de se comporter soudainement de manière dynamique. Exemple : jQuery version x.
Dans son principe, SRI cible le « facteur de changement » en vérifiant que le contenu d'un script reste identique à sa version connue et de confiance.
Pourquoi SRI a été ajouté à CSP
Au fil des années, de plus en plus de fonctionnalités de SRI ont été intégrées aux Content Security Policies (CSP). Ce qui a soulevé la question : pourquoi les deux ? La sécurité repose sur la superposition de couches, il est donc utile d'avoir des options. Cependant, la limitation de CSP — qui n'interagit pas activement avec le contenu des scripts — a conduit logiquement à envisager l'ajout de hachages à la spécification.
Pendant longtemps, CSP ne faisait que faire confiance aux sources, ce qui a engendré le problème suivant. Imaginez que deux colis arrivent à votre porte. Tous deux proviennent du même expéditeur, mais l'un contient un adorable chiot et l'autre une bombe à paillettes.
Dites-moi, rien qu'à l'adresse de l'expéditeur, lequel est lequel ?
L'argument ici est le suivant : ne faites pas confiance aux sources, vérifiez leur contenu servi. Il est juste de dire qu'une fois qu'un contenu malveillant provient d'une source, cette source n'est plus considérée comme fiable. Mais pour que cela soit actionnable, vous devez quand même vérifier ce que fait la source.
La Subresource Integrity ne fonctionne pas sur le web dynamique d'aujourd'hui
Pour garantir la prévisibilité du contenu des scripts, SRI a représenté une avancée majeure. La Subresource Integrity est efficace pour les scripts statiques et versionnés, mais elle échoue face aux scripts dynamiques.
La plupart des scripts récupérés côté client en 2025 sont dynamiques, et pour de bonnes raisons. Ils adaptent le contenu en fonction de la géographie de l'utilisateur, du type d'appareil, des fonctionnalités du navigateur ou des exigences de personnalisation. Chacun de ces changements légitimes pourrait invalider le hachage utilisé par SRI.
Combiner SRI avec un outil de surveillance des scripts dynamiques
Avec cside, SRI peut être appliqué de manière plus efficace. cside détecte les scripts statiques et vous aide à générer les en-têtes SRI correspondants. Les scripts dynamiques sont traités différemment, avec d'autres protocoles de sécurité tels qu'un moteur d'inspection des scripts piloté par l'IA.
Les outils de scan ne peuvent pas vérifier l'intégrité des scripts
Les scripts côté client sont servis différemment selon les User Agents, les adresses IP des requêtes, les pays, l'heure de la journée, etc. Tout élément contenu dans un en-tête de requête peut entraîner une réponse différente côté serveur. Il n'est pas rare qu'un script côté client serve aléatoirement des contenus différents.
En raison de cette variabilité, les approches basées sur des scanners ne constituent pas une méthode fiable pour vérifier l'intégrité des scripts. Les attaquants peuvent facilement détecter quand un crawler ou un outil automatisé demande le fichier. Ils servent simplement une version propre au scanner et délivrent la charge malveillante à un sous-ensemble ciblé d'utilisateurs réels.
Mises à jour de la Subresource Integrity
Depuis la sortie initiale de SRI, diverses améliorations ont été apportées. Une préoccupation courante avec SRI était que si le hachage d'un script ne correspondait pas, le script était bloqué mais aucune API de reporting n'était disponible, ce qui entraînait une page cassée sans aucune alerte pour le propriétaire du site.
Cependant, avec la spécification Integrity Policy mise à jour, cela est désormais possible.
cside contribue aux améliorations de SRI
De nouvelles spécifications sont proposées pour SRI, auxquelles cside a contribué. En tant que membre actif du w3c (l'organisation principale qui développe les standards du web), cside a formulé des suggestions pour de meilleures spécifications concernant la gestion dynamique des hachages de scripts.
En l'état actuel, les hachages de scripts codés en dur présentent des défis que la plupart des entreprises ne peuvent pas se permettre. En attendant, SRI peut être un outil utile pour les scripts statiques ou prévisibles, mais ce n'est pas la solution complète pour garantir l'intégrité des scripts.
Comment vérifier l'intégrité des scripts pour la conformité
Utiliser un outil de sécurité côté client
Bien que la définition exacte de « l'intégrité des scripts » soit interprétée différemment selon les référentiels, un point fait l'objet d'un large consensus : les outils vendeurs préconstruits constituent la voie la plus pratique pour vérifier l'intégrité des scripts. Un développement interne de ces capacités prendrait des mois et devrait être continuellement maintenu à mesure que les attaquants font évoluer leurs techniques.
Lors de notre récent webinaire avec BARR Advisory, le consultant en conformité Kyle Kofsky l'a dit clairement : la recommandation par défaut pour les organisations qui abordent les exigences d'intégrité des scripts PCI DSS 6.4.3 & 11.6.1 est d'adopter une solution vendeur éprouvée.
Utiliser cside pour vérifier l'intégrité des scripts
Avec la solution de sécurité des scripts de cside, il vous suffit d'ajouter un script à votre site web et nous surveillons le comportement de chaque script sur votre site. Vous disposez d'un tableau de bord pour comprendre les données auxquelles chaque script accède, où il les envoie, comment ces comportements ont évolué dans le temps, ainsi que l'origine du script et les éventuelles améliorations de performance possibles.
Ces informations sont automatiquement documentées dans le format requis par vos exigences de conformité. Qu'il s'agisse de normes de confidentialité comme le RGPD, le CCPA, ou de normes de sécurité visant à lutter contre les scripts malveillants comme PCI DSS 4.0.1, ISO 27001 et HIPAA. Notre solution répond à ces exigences et les dépasse, et est validée par les évaluateurs de premier rang du secteur. Consultez notre livre blanc avec Vikingcloud ici.
cside souhaite rendre le web plus sûr. En utilisant notre solution, vous donnez à l'équipe les moyens de pousser les organismes du secteur à permettre des mécanismes de sécurité plus simples et plus robustes dans les navigateurs. Nous sommes transparents sur nos limites et nous œuvrons pour un monde plus sûr. Notre motivation : protéger nos proches de l'anxiété liée à la sécurité en ligne et éviter aux marchands d'avoir à augmenter leurs prix pour compenser la fraude.
