La JavaScript injection est l'insertion d'un script contrôlé par un attaquant dans une page web de sorte qu'il s'exécute dans le navigateur des visiteurs avec les mêmes privilèges que le code de la page elle-même. Une fois lancé, le script injecté peut lire le DOM, capturer ce que les utilisateurs tapent et envoyer des données n'importe où — le mécanisme derrière le formjacking, Magecart et la plupart des vols de données client-side.
Comment le JavaScript est-il injecté ?
| Voie d'injection | Comment ça fonctionne | Qui est compromis |
|---|---|---|
| XSS (réfléchi / stocké / basé sur le DOM) | Une faille du site permet à l'entrée de l'attaquant de s'exécuter comme script | Le propre code du site |
| Supply chain tierce | Un fournisseur dont vous chargez le tag livre du code malveillant — par compromission ou par rachat | Le fournisseur (Polyfill.io est le cas canonique) |
| Domaines expirés / imitations | Un attaquant prend le contrôle d'un domaine depuis lequel votre page charge encore des scripts | La chaîne de dépendances |
| Abus du tag manager | Un compte de tag manager compromis injecte « juste un tag de plus » | Votre stack marketing |
| Malwares / extensions côté client | Le script est injecté sur la machine du visiteur, dans tous les sites | Le navigateur du visiteur |
La première voie est une faille de code que vous pouvez corriger. Les trois du milieu sont des failles de confiance : le code a été invité. Une page moderne exécute des dizaines de scripts tiers, et chacun d'eux est un vecteur d'injection avec les pleins privilèges de la page — le problème central de la sécurité client-side.
Ce que font les scripts injectés
Le code injecté n'a aucune frontière de privilèges le séparant du vôtre. Dans les attaques observées, il skimme les formulaires de paiement caractère par caractère, moissonne les identifiants sur les pages de connexion, superpose de faux champs de paiement sur les champs légitimes, détourne les revenus d'affiliation, redirige les sessions et transmet les données volées à l'infrastructure de l'attaquant — souvent des domaines nommés pour ressembler à l'adtech ordinaire de votre onglet réseau.
Prévention : réduire les voies d'entrée
- Corrigez la classe XSS : encodage des sorties, sinks sûrs, assainissement, Trusted Types.
- Restreignez les sources avec une Content Security Policy : une CSP stricte basée sur des nonces bloque les origines de script non autorisées — avec des limites connues : elle ne peut pas juger ce que fait un script autorisé après son chargement.
- Épinglez ce que vous pouvez : Subresource Integrity pour les dépendances statiques ; minimisez le rayon d'impact du tag manager.
- Réduisez l'arbre de dépendances : chaque script tiers supprimé est une voie d'injection supprimée.
Détection : surveiller l'exécution
La prévention réduit la probabilité ; elle ne peut pas atteindre la compromission d'un fournisseur de confiance. La détection doit se faire là où l'injection atterrit — le navigateur. La surveillance de scripts de cside inventorie chaque script qui s'exécute dans des sessions réelles, analyse les payloads et alerte sur les nouveaux domaines, le code modifié et les flux de données inattendus. Sur les pages de paiement, cet inventaire à l'exécution est aussi une exigence de conformité : les exigences 6.4.3 et 11.6.1 de PCI DSS 4.0.1 existent précisément parce qu'un script injecté sur une page de paiement est invisible pour tout contrôle côté serveur.
