La gestion du risque des scripts tiers est le modèle opérationnel qui consiste à faire tourner le JavaScript externe comme un programme gouverné plutôt que comme une porte ouverte. Le cadre comporte six pièces mobiles : inventaire, ownership, classification d'accès aux données, monitoring de changements, cadence de revue et preuve. Faites fonctionner ces six ensemble et vous pourrez répondre aux seules questions qui comptent lors d'un incident ou d'un audit : qu'est-ce qui tourne, qui en est propriétaire, qu'est-ce que ça peut toucher et qu'est-ce qui a changé.
La plupart des équipes ont des tactiques sans programme. Elles font tourner une Content Security Policy, épinglent peut-être quelques hashes Subresource Integrity et gardent un tableur de vendors devenu obsolète le jour où un tag manager a ajouté un script de quatrième partie que personne n'avait approuvé. Cet article décrit le modèle de gouvernance dans lequel ces tactiques s'insèrent, les rôles qui le font tourner et la preuve côté navigateur que cside produit pour rendre chaque partie réelle.
Le modèle opérationnel en six parties
Chaque partie du cadre répond à une question qu'un attaquant ou un évaluateur posera. Si une colonne est vide, c'est votre exposition.
| Pilier | La question à laquelle il répond | Preuve à conserver |
|---|---|---|
| Inventaire | Qu'est-ce qui s'exécute réellement dans le navigateur ? | URL du script, source/quatrième partie, date de première apparition, version |
| Ownership | Qui est accountable pour ce script ? | Owner nommé, justification business, enregistrement d'approbation |
| Tier d'accès aux données | Que peut lire ou envoyer ce script ? | Accès aux champs, cookies, tokens ; label de tier |
| Monitoring de changements | Qu'est-ce qui a changé, et était-ce autorisé ? | Diffs, nouvelles destinations, alerte + résolution |
| Cadence de revue | Quand a-t-il été réattesté pour la dernière fois ? | Date de dernière revue, relecteur, prochaine échéance |
| Preuve | Pouvons-nous prouver tout ce qui précède ? | Timeline immuable par PCI 6.4.3 / 11.6.1 |
Construisez l'inventaire depuis le navigateur, pas depuis un tableur
Une liste de vendors n'est pas un inventaire. Un vendor approuvé peut charger des scripts chaînés que vous n'avez jamais revus, et les tag managers injectent du code à l'exécution qu'aucun scan côté serveur ne voit. Votre inventaire doit venir de ce qui s'exécute réellement dans les navigateurs des vrais utilisateurs, y compris les quatrièmes parties que vos tiers ramènent.
cside construit cet inventaire depuis l'observation en direct du navigateur : chaque script, sa source réelle, quand il est apparu pour la première fois et ce qu'il fait une fois lancé. C'est l'épine dorsale sur laquelle les cinq autres piliers s'accrochent, parce que vous ne pouvez pas attribuer un owner ou un tier de données à un script que vous ne voyez pas.
Attribuez un owner par script, puis rendez les rôles explicites avec un RACI
Un inventaire sans ownership est une liste d'orphelins. Chaque script a besoin d'un humain nommé capable d'énoncer sa justification business et d'approuver ses changements. Mais « owner » seul devient vite flou dans un incident, alors répartissez le travail entre les rôles avec un RACI simple : qui est Responsible, Accountable, Consulted et Informed pour chaque partie du programme.
| Activité | Owner du script | Engineering | Sécurité | Privacy | Compliance |
|---|---|---|---|---|---|
| Maintenir l'inventaire en direct | C | R/A | I | I | I |
| Approuver un nouveau script / justification | A | R | C | C | I |
| Classer le tier d'accès aux données | C | I | C | A/R | I |
| Enquêter sur une alerte de changement | C | C | A/R | C | I |
| Autoriser un blocage | A | R | C | I | I |
| Produire la preuve d'audit | C | I | C | C | A/R |
Une règle maintient l'honnêteté : chaque ligne a exactement un Accountable. Quand PCI DSS 6.4.3 vous demande de justifier et d'autoriser chaque script de page de paiement, « qui a approuvé ça » doit se résoudre en un nom, pas en un haussement d'épaules. Le RACI est ce qui transforme l'inventaire d'une liste en un programme que des gens font tourner.
Classez l'accès aux données en tiers
Tous les scripts ne méritent pas la même confiance. Classez selon ce qu'ils peuvent atteindre dans le navigateur, puis gouvernez chaque tier différemment. Un pixel marketing qui lit un formulaire de checkout est le motif exact derrière Magecart et le vol par e-skimming, donc la classification doit être comportementale, pas seulement basée sur la réputation du vendor.
| Tier | Données que le script peut toucher | Gouvernance |
|---|---|---|
| Tier 1, sensible | Champs de paiement, identifiants, tokens de session | Revue à chaque changement ; default-deny sur actions risquées |
| Tier 2, personnel | Inputs de formulaire, cookies identifiables | Approuver l'accès, surveiller les destinations |
| Tier 3, faible | Pas de PII, assets statiques uniquement | Revue périodique légère |
cside vous permet de définir une politique comportementale par script : un widget de chat peut se rendre sans lire le champ de paiement à côté de lui, et un tag d'analytics peut tourner tout en étant bloqué des cookies ou des inputs de formulaire. Cela transforme le label de tier en une règle appliquée plutôt qu'en une note dans un tableur.
Surveillez les changements, parce que l'approbation est un instant et que les scripts sont continus
L'angle mort dangereux dans la plupart des programmes, c'est le temps. Un script est approuvé une fois, puis change silencieusement pendant des mois. Les contrôles statiques le manquent : une CSP ne gouverne que l'origine de chargement, et un hash SRI protège un fichier statique mais casse sur les scripts dynamiques dont la plupart des sites modernes dépendent, donc les équipes le lâchent. L'approbation est un instantané ; le risque est un film.
Le monitoring de changements ferme l'écart en observant le comportement à l'exécution, pas seulement le domaine source. Quand un script Tier 1 commence à lire un champ qu'il n'avait jamais touché, envoie un beacon vers une nouvelle destination, ou son payload évolue, c'est le signal. cside capture le comportement à l'exécution, les changements de payload et les nouvelles destinations réseau, puis alerte sur les changements non autorisés. Cette même capture est ce qu'attend PCI DSS 11.6.1 : détecter et alerter sur la modification non autorisée des scripts de page de paiement et des en-têtes HTTP, au moins hebdomadairement ou selon votre analyse de risque sous l'exigence 12.3.1.
Fixez une cadence de revue liée au tier de données
La cadence empêche le programme de pourrir entre deux incidents. Pilotez-la sur le tier, pas sur le seul calendrier :
- Scripts Tier 1 : réattester à chaque changement et au moins trimestriellement.
- Scripts Tier 2 : revoir trimestriellement et à toute nouvelle destination.
- Scripts Tier 3 : revoir annuellement, ou chaque fois qu'ils montent d'un tier.
- Tout nouveau script non approuvé : revoir à la détection, sans attendre.
Une revue qui ne produit pas d'enregistrement est une conversation, pas un contrôle. Chaque passage doit laisser une note datée : qui a revu, ce qui a été vérifié et ce qui est dû ensuite.
Évaluez votre programme contre un modèle de maturité
Un cadre n'aide que si vous savez où vous y tenez. Utilisez ces cinq niveaux pour scorer le programme honnêtement, par surface. Vos pages de paiement peuvent se situer à un niveau différent de votre site marketing, et l'écart entre les deux est généralement là où vit le risque.
| Niveau | État | À quoi ça ressemble | Posture d'audit |
|---|---|---|---|
| 1, Ad hoc | Pas d'inventaire | Scripts ajoutés par n'importe qui, pas de liste, pas d'owners | Échec à 6.4.3 dès le premier jour |
| 2, Documenté | Tableur statique | Une liste de vendors existe mais devient obsolète ; pas de quatrièmes parties | Inventaire existe, intégrité non prouvée |
| 3, Owned | RACI attribué | Owners nommés, justifications, revue périodique manuelle | Peut montrer l'autorisation, faible en détection de changements |
| 4, Monitored | Alertes de changement runtime | Monitoring comportemental, politique par tiers, alertes résolues | Répond à l'intention de 11.6.1 |
| 5, Continuous | Preuve à la demande | Inventaire en direct, tiers appliqués, timeline immuable exportable à la demande | Prêt pour l'audit sans simulacre d'incendie |
La plupart des équipes découvrent qu'elles sont au niveau 2 sur la surface qui compte le plus. Le saut qui compte est du niveau 3 au niveau 4 : passer de « nous avons une liste et des owners » à « nous sommes alertés dès qu'un script Tier 1 change de comportement ». C'est la ligne entre un classeur et un contrôle, et c'est là que la monitoring en couche navigateur gagne sa place.
Conservez une preuve qu'un auditeur acceptera
Le cadre ne compte que si vous pouvez prouver qu'il a tourné. Pour PCI DSS 4.0.1, cela signifie un inventaire avec justification documentée pour chaque script de page de paiement (6.4.3) et une trace d'alertes de tamper pour les changements non autorisés des scripts et des en-têtes HTTP (11.6.1), tous deux obligatoires depuis 2025-03-31. Un processeur de paiement comme Stripe ou Adyen ne rend pas votre propre page conforme. Les scripts sur votre checkout restent sous votre responsabilité, et un iframe tiers ne déplace pas cette ligne.
cside conserve cela comme une timeline immuable et interrogeable : ce qu'est chaque script, qui l'a approuvé, les données auxquelles il a accédé, chaque changement, chaque alerte et comment chacune a été résolue. Quand l'évaluateur demande « montrez-moi », vous exportez un enregistrement au lieu de le reconstruire de mémoire. La couche navigateur compte ici aussi : cside capture les signaux d'appareil et d'IP réelle, le comportement des agents IA et des bots, et les patterns VPN/proxy, donc la preuve reflète ce qui a réellement tourné pour de vrais utilisateurs plutôt que ce qu'un crawler périodique a vu par hasard. Les signaux sont disponibles via API, pour que l'inventaire et les alertes alimentent vos propres outils GRC ou SIEM.
Pourquoi un programme bat une checklist en 2026
La pression de l'automatisation monte du côté attaquant. La propre recherche de cside a constaté que les installations de playwright-stealth ont grimpé d'environ dix fois durant 2025, ce qui signifie plus d'activité automatisée et évasive sondant les surfaces client-side (rapport de recherche cside). Les crawlers qui scannent périodiquement sont précisément ce que l'automatisation évasive est conçue pour esquiver : servir du code propre au scanner, le payload malveillant à la vraie session. Un tableur statique annuel ne peut pas suivre ce rythme ; un modèle opérationnel continu avec owners, tiers et alertes de changement sur les vrais utilisateurs le peut. Le cadre est ce qui transforme un tas de scripts en quelque chose que vous gouvernez.
Lectures complémentaires sur cside
- Bonnes pratiques pour sécuriser les scripts tiers
- Principales plateformes de monitoring de scripts tiers
- Comment se conformer à PCI 6.4.3 et 11.6.1
- Qu'est-ce que la client-side security ?
- cside PCI Shield
- Conformité à la directive NIS2 et obligations des scripts tiers sur les sites web
Au 2026-06-18, considérez ceci comme une orientation opérationnelle, pas comme un avis juridique. Confirmez le libellé exact du contrôle avec votre QSA, votre conseil juridique ou votre responsable des risques.
