Site WordPress infecté : vérifier les fichiers JavaScript chargés

Quand un site WordPress commence à se comporter “bizarrement”, la première réaction est souvent de chercher un plugin suspect ou une porte dérobée dans les fichiers PHP. C’est https://gardewp.fr/ logique. Pourtant, dans beaucoup d’incidents récents, l’attaque se voit d’abord côté navigateur, dans les scripts JavaScript chargés et exécutés. Le symptôme peut être discret, une redirection au moment du clic, une carte de paiement qui n’affiche pas ce qu’elle devrait, des pop-ups, ou un comportement qui disparaît quand on recharge en mode navigation privée. Dans ces cas-là, vérifier les fichiers JavaScript chargés devient une méthode très concrète pour confirmer ou infirmer un compromis.

Je l’ai vécu sur un site qui semblait “presque normal”. Les pages affichaient correctement le contenu, mais les performances chutaient brutalement sur certaines URL. En ouvrant l’inspecteur, le problème s’est révélé très vite: un petit script chargé depuis un domaine étrange s’exécutait uniquement sur certains chemins, puis déclenchait un chargement additionnel. Tant que je n’avais pas regardé ce qui arrivait vraiment au navigateur, je perdais du temps sur les fichiers côté serveur.

Dans cet article, je vais expliquer une approche pragmatique pour inspecter les scripts JavaScript réellement chargés sur votre WordPress, afin de repérer ce qui n’aurait jamais dû être là. L’objectif n’est pas de “tout supprimer”, mais de comprendre la chaîne d’exécution, puis de décider quoi isoler, quoi supprimer, et quoi vérifier ensuite.

Pourquoi le JavaScript est souvent le premier indice

Un site WordPress infecté peut cacher l’injection à plusieurs endroits. Le plus courant est l’ajout d’un script dans les pages rendues par WordPress, via un hook, un fichier d’extension compromis, ou une modification dans un thème. Mais l’attaque peut aussi se traduire par un chargement conditionnel: le script ne s’envoie pas à tout le monde, il se déclenche seulement sur certains navigateurs, ou seulement quand certains paramètres d’URL sont présents.

JavaScript est idéal pour les attaquants parce qu’il peut:

charger d’autres ressources après coup, modifier le DOM et les liens affichés, retarder une redirection pour contourner certaines vérifications, collecter des informations côté client (sans forcément exfiltrer immédiatement).

Même si la “source de l’infection” est PHP, le navigateur peut montrer la trace la plus nette, parce que les scripts se chargent dans un ordre précis, avec des URL visibles.

Préparer l’inspection: viser le navigateur réel et le bon scénario

Avant d’analyser quoi que ce soit, faites deux choses simples. D’abord, reproduisez le comportement exactement comme un utilisateur: même URL, même langue, mêmes cookies si possible. Ensuite, évitez de confondre un bug de cache ou un comportement normal avec une injection.

J’ai déjà vu des “faux positifs” venir de scripts de tracking légitimes, ou d’un CDN qui change d’URL selon le contexte. Pour éviter ça:

testez en navigation privée et en session normale, pour comparer les scripts chargés avec et sans cookies, testez depuis deux navigateurs (Chrome et Firefox par exemple), car certains scripts conditionnent le chargement, si le site a des pages différentes, inspectez une page “normale” et une page “problématique”.

L’idée est de créer un contraste. Quand quelque chose n’apparaît que sur une URL précise, l’analyse devient beaucoup plus rapide.

Regarder la page rendue: sources, balises script, et attributs suspects

La première étape consiste à ouvrir la page et à regarder le HTML rendu. Dans l’inspecteur, basculez sur l’onglet “Elements” (ou “Éléments”), puis cherchez les balises . À ce stade, vous cherchez surtout des signaux:</p> des scripts chargés depuis des domaines qui n’ont rien à voir avec votre activité, des scripts en http:// au lieu de https:// (même si ce n’est pas une preuve à lui seul), des scripts avec des noms de fichiers incohérents, des chaînes très longues, ou des variables “minifiées” mais non identifiables, des tags qui utilisent data: ou des URIs bizarres. <p> Attention, un script peut être “minifié” et pourtant légitime (beaucoup de fichiers de performance le sont). Ce qui vous aide, c’est l’association entre le script et votre réalité: utilisez-vous ce domaine pour le tracking, les formulaires, le chat, la cartographie, ou l’analytics? Si non, méfiez-vous.</p> <p> Un point utile: dans l’onglet “Elements”, vérifiez si l’injection se trouve directement dans le HTML, ou si elle apparaît via un script qui construit ensuite d’autres balises. Parfois, le HTML ne contient qu’un petit chargeur, et le gros du comportement vient ensuite.</p> <h2> Utiliser le panneau Réseau pour confirmer les fichiers réellement chargés</h2> <p> L’erreur classique consiste à se baser uniquement sur le HTML affiché, alors que le navigateur peut charger des scripts supplémentaires après coup. Le panneau Réseau (Network) est celui qui tranche.</p> <p> Procédure pratique: ouvrez les outils de développement, allez dans l’onglet Réseau, cochez “Preserve log” si disponible, puis rechargez la page. Filtrez ensuite par “JS” pour n’afficher que les ressources JavaScript.</p> <p> Vous verrez alors une liste d’URL. C’est là que l’enquête devient concrète. Un script malveillant laisse souvent plusieurs traces:</p> un fichier JavaScript chargé depuis un domaine inconnu, une ressource avec un timing très spécifique (par exemple après une interaction ou après quelques secondes), des requêtes en cascade (un script A charge un script B, puis B charge C). <p> Si votre site WordPress infecté utilise une injection “propre”, vous pouvez voir le script apparaître uniquement sur certaines pages. Par exemple, un script peut se charger sur /product/ mais pas sur la page d’accueil. Ou l’injection peut se limiter aux utilisateurs qui viennent de certaines sources, via referrer.</p> <h2> Repérer les scripts injectés: signaux “visibles” et signaux “fonctionnels”</h2> <p> Quand vous identifiez un fichier JavaScript “suspect”, ne vous contentez pas de l’exclure. Essayez de comprendre sa place dans la chaîne.</p> <p> Voici ce que j’observe presque à chaque fois dans des incidents:</p> <p> 1) Le script suspect est chargé, puis il y a immédiatement d’autres requêtes. Si vous voyez un effet en chaîne, le script n’est pas juste un fichier inutile, il sert probablement de chargeur.</p> <p> 2) Le fichier est souvent petit (quelques kilo-octets) mais déclenche beaucoup d’actions ensuite. Un chargeur peut être compact et “faire faire” le reste.</p> <p> 3) Le contenu est parfois obfusqué, mais il faut rester prudent. L’obfuscation n’est pas une preuve en soi. Ce qui compte, c’est l’URL de provenance, la cohérence avec votre stack, et la finalité.</p> <p> 4) Si le script s’exécute, vous verrez parfois des changements dans le DOM. En Réseau, vous ne verrez pas tout, mais vous pouvez ensuite retourner dans “Elements” et observer des modifications.</p> <p> Un autre détail utile: dans le panneau Réseau, regardez le statut et la réponse. Un fichier 200 sur un domaine inconnu, sans logique métier associée, est un drapeau rouge. Un 404 sur une ressource suspecte peut aussi être intéressant si l’attaque tente de charger quelque chose puis échoue.</p> <h2> Comparer avec une base saine: votre propre “référence”</h2> <p> Si vous avez accès à une sauvegarde saine, ou à un environnement de test où tout était stable, c’est un accélérateur. Dans mon expérience, les scripts de base d’un WordPress changent moins vite que l’on ne le pense.</p> <p> Comparez:</p> la liste des scripts sur une page identique entre la version saine et la version infectée, les URL des ressources JavaScript, l’ordre de chargement. <p> Si vous n’avez pas de copie saine, vous pouvez aussi utiliser l’historique de déploiement. Voyez quand les plugins ont été mis à jour, quand le thème a changé, et quand des modifications de configuration sont apparues côté serveur. Un écart récent coïncide souvent avec l’injection.</p> <h2> Trois endroits où la plupart des injections se cachent dans WordPress</h2> <p> Je ne vais pas prétendre qu’il n’y a que trois endroits, mais en pratique, beaucoup d’incidents passent par un petit ensemble de mécanismes.</p> <p> D’abord, les thèmes et leurs fichiers peuvent être modifiés, y compris des “fichiers à faible importance” comme des fichiers d’options ou des includes conditionnels. Ensuite, les plugins peuvent être compromis, parfois même des plugins qui ne semblent pas “directement liés” à la page concernée. Enfin, WordPress peut être victime d’altérations dans les mécanismes qui injectent du code dans la page, via des hooks.</p> <p> À ce stade, vous allez peut-être vous dire: “Je vois le script côté navigateur, mais je ne sais pas d’où il vient.” C’est normal. L’inspection du JavaScript est le diagnostic, puis il faut remonter vers la cause.</p> <h2> Chercher la trace dans le HTML: localisation du point d’injection</h2> <p> Quand vous avez une URL de script suspecte, cherchez son emplacement dans le HTML rendu. L’idée est de trouver quel morceau de page le génère.</p> <p> Dans l’inspecteur “Elements”, localisez la balise <script src="..."> correspondante. Ensuite, observez autour: parfois, vous voyez un commentaire, un attribut, ou une structure qui indique une source. Par exemple, un script peut être inséré au niveau du <head>, ou juste avant la fermeture du <body>. Cette position peut orienter votre investigation.</p> <p> Si vous utilisez un outil qui affiche le “view source” brut, comparez avec la page rendue dans le navigateur. WordPress peut injecter en fonction de filtres, et le HTML brut affiché dans la source n’expose pas toujours tout.</p> <p> Dans certains cas, vous verrez un script inline, souvent obfusqué, qui ajoute ensuite des éléments DOM pour charger une ressource externe. Là, le script inline est votre cible. Même si votre regard se concentre sur les fichiers JS chargés, le script inline est souvent la main qui lance l’infection.</p> <h2> Mini-checklist pour trier le suspect (sans se perdre)</h2> <p> Voici une grille courte que j’utilise pour décider rapidement si un script mérite une enquête approfondie.</p><p> <img src="https://i.ytimg.com/vi/KlZUkRoI3Ug/hq720.jpg" style="max-width:500px;height:auto;" ></img></p> Domaine inconnu ou non utilisé dans votre stack (tracking, chat, analytics, maps) Requêtes en chaîne après chargement (un JS déclenche d’autres JS ou des endpoints) Chargement conditionnel (uniquement sur certaines URL, ou seulement pour certains contextes) Présence d’obfuscation lourde combinée à une provenance douteuse Timing anormal (chargement après quelques secondes ou après une action, sans raison métier) <p> Si au moins deux points sont cochés, je considère que le script doit être traité comme suspect, même si je ne peux pas le “prouver” à 100% dès la première lecture.</p> <h2> Outil pratique: observer ce que fait le script pendant l’exécution</h2> <p> Une URL suspecte seule ne dit pas toujours ce qu’elle fait. C’est pour ça que l’exécution compte.</p> <p> Dans la console et l’inspecteur, vous pouvez:</p> placer un point d’arrêt (breakpoint) sur l’exécution du fichier (si vous comprenez comment s’en servir, ça vaut le coup), surveiller les erreurs JavaScript, observer les modifications DOM. <p> Je fais souvent un test simple: je recharge la page, puis je surveille si des actions apparaissent sans interaction, par exemple des redirections déclenchées, des iframes injectées, ou des formulaires masqués.</p> <p> Quand le script est actif, vous verrez des changements perceptibles en quelques secondes. Les scripts inactifs ou simplement “présents” ne provoquent pas de cascade.</p> <h2> Que faire une fois le fichier suspect identifié</h2> <p> L’étape suivante n’est pas de “supprimer au hasard”. Si vous coupez un script qui est en réalité un composant légitime, vous pouvez casser le fonctionnement du site. L’approche la plus sûre consiste à isoler et à réduire le risque progressivement, tout en gardant la capacité de revenir en arrière.</p> <p> Voici ce que je fais généralement, dans un ordre qui minimise le chaos:</p> <p> 1) Isoler la page et confirmer que le script suspect se charge bien dans le contexte reproduit.</p> 2) S’assurer qu’il n’est pas lié à une intégration légitime récente (nouveau plugin, nouvelle intégration de tracking, widget). 3) Remonter au point d’injection côté WordPress, puis corriger la cause. 4) Pendant la correction, limiter les dégâts avec des mesures temporaires contrôlées (exemple: blocage au niveau serveur ou désactivation ciblée), sans toucher tout le site. 5) Après correction, vérifier à nouveau via le panneau Réseau que les scripts ne se chargent plus. <p> Pour décider rapidement, je garde la règle suivante: on traite d’abord la cause côté WordPress, pas seulement le symptôme côté navigateur. Bloquer un script malveillant est utile, mais si vous ne corrigez pas l’injection, vous risquez d’avoir une variante qui change d’URL ou qui injecte autrement.</p> <h2> Mesures temporaires: utiles, mais avec prudence</h2> <p> Quand un site est réellement en situation de compromission, on veut réduire l’impact tout de suite. Mais les mesures temporaires peuvent masquer le problème, ou casser une partie du site.</p> <p> Selon votre configuration et votre niveau d’accès, des actions temporaires peuvent inclure:</p> désactiver temporairement un thème ou un plugin récemment ajouté, sur une base de test, restaurer des fichiers d’un thème ou d’un plugin depuis une copie connue propre, appliquer des règles de sécurité au niveau serveur pour bloquer un domaine suspect, mettre le site en maintenance si le trafic est suffisamment critique. <p> Le point clé, c’est de ne pas agir “à l’aveugle” sur le code principal. Un bon diagnostic JavaScript aide à cibler.</p> <h2> Débordement fréquent: le script “suspect” n’est pas le mal, il est le témoin</h2> <p> Un cas qui arrive souvent: le script que vous voyez chargé n’est pas celui qui a été injecté à l’origine. Il peut être chargé par un autre mécanisme, par exemple un script inline ou un petit loader. Si vous vous concentrez uniquement sur le fichier externe, vous risquez de laisser intact le point d’injection.</p> <p> C’est pour ça que l’inspection “Révéler la cascade” est importante. Dans le panneau Réseau, suivez le fil:</p> quel script s’est chargé en premier parmi les suspects, lequel a déclenché lequel, s’il existe une requête initiale vers un endpoint qui renvoie ensuite des scripts. <p> Quand vous trouvez le premier maillon, vous réduisez la surface de réparation.</p> <h2> Exemple concret d’un scénario typique</h2> <p> Imaginons un site WordPress dont la page d’accueil charge normalement environ 10 à 25 fichiers JavaScript. Un après-midi, après une mise à jour d’un plugin de formulaire, les utilisateurs voient des pop-ups. Dans le panneau Réseau, vous filtrez sur JS, et vous repérez un fichier widget-init.js chargé depuis cdn-something-rare.com.</p> <p> Ce fichier ne ressemble pas à un plugin connu. Il se charge en quelques centaines de millisecondes, puis dans la seconde suivante, vous voyez:</p> une requête vers un endpoint qui renvoie un autre JavaScript, un chargement d’une ressource qui crée une iframe, et enfin une redirection déclenchée. <p> Dans ce scénario, je ne “supprimerais” pas uniquement widget-init.js. Je remonterais aussi vers le script qui l’a injecté, au niveau WordPress. Souvent, la balise <script> qui déclenche la charge se trouve dans un hook de thème, ou dans le fichier d’un plugin compromis. Une fois corrigé, la chaîne en cascade disparaît, pas seulement le dernier maillon.</p> <h2> Comment éviter de confondre attaque et normalité</h2> <p> Un dernier piège, très humain, c’est de trouver quelque chose de “pas clair” et d’en conclure à une infection. Les sites WordPress utilisent souvent des scripts externes: consentement cookies, analytics, tags marketing, recaptcha, chat, maps, bundles de scripts de performance.</p> <p> Pour éviter ça, je me base sur trois critères combinés:</p> La provenance: est-ce un domaine que vous avez installé intentionnellement, ou un domaine que vous n’avez jamais autorisé? Le comportement: le script déclenche-t-il des actions visibles, une cascade, une redirection? La cohérence: la présence du script correspond-elle à un composant en place (nom de plugin, widget, configuration)? <p> Quand un script “inconnu” ne déclenche rien et se charge en arrière-plan sans effet observable, ça mérite une vérification, mais ce n’est pas toujours une infection. Quand un script “inconnu” déclenche une cascade, là, je ne négocie plus.</p> <h2> Vérification finale: s’assurer que plus rien ne se charge “anormalement”</h2> <p> Après correction, revenez dans le navigateur et refaites la même inspection que celle qui a déclenché l’enquête. Je recommande de conserver une trace de votre analyse initiale: les URL suspectes, l’ordre de chargement, et les pages concernées.</p><p> <img src="https://i.ytimg.com/vi/dlrZoyYyFB4/hq720_2.jpg" style="max-width:500px;height:auto;" ></img></p> <p> Côté navigateur, vous cherchez:</p> la disparition des URLs externes suspectes, l’absence de requêtes en cascade liées au script, une différence nette dans le panneau Réseau sur les pages touchées. <p> Si vous avez un plan de surveillance (logs, alertes, scan malware côté serveur ou externe), activez-le aussi. Mais la vérité reste celle du navigateur: ce que l’utilisateur charge et exécute.</p> <h2> Si vous devez décider rapidement: priorités réalistes</h2> <p> Parfois, vous devez agir avec peu de temps. Dans ces moments, je privilégie une stratégie qui réduit le risque sans casser l’activité.</p> <p> Voici une liste courte de priorités typiques quand vous suspectez un site WordPress infecté lié à du JavaScript.</p> Confirmer l’URL de script suspecte et sur quelles pages elle se charge Chercher le point d’injection côté WordPress (thème, plugin, hook) Restaurer les fichiers depuis une source propre quand c’est possible Corriger la cause, puis valider à nouveau via le panneau Réseau Mettre en place une surveillance et renforcer l’accès (mots de passe, mises à jour) <p> Même si vous n’avez pas le temps de tout investiguer en profondeur dès le jour 1, vous devez au moins supprimer la capacité du code à réinjecter le comportement.</p> <h2> Renforcer la prévention après l’incident</h2> <p> Une fois l’injection corrigée, le travail continue. Le JavaScript suspect est souvent un symptôme, pas une cause. La cause est fréquemment un plugin vulnérable, un thème modifié, une compromission de compte admin, ou une mauvaise configuration d’accès.</p> <p> La prévention efficace n’a pas besoin d’être compliquée. Elle consiste surtout à maintenir un cadre où les injections ont moins de chances d’exister, et où elles sont détectées plus vite.</p> <p> Par exemple, gardez une discipline de mise à jour, limitez le nombre de plugins, surveillez les modifications de fichiers, et sécurisez l’accès au panneau d’administration. Ajoutez aussi une routine d’audit: une fois par mois, inspecter rapidement les scripts externes chargés sur vos pages clés, surtout celles qui ont des formulaires ou des paiements.</p> <p> Vérifier les fichiers JavaScript chargés dans un incident WordPress, ce n’est pas seulement “chercher un virus”. C’est une méthode d’observation qui donne des réponses concrètes: quels scripts arrivent, quand ils arrivent, et comment ils déclenchent le reste. Une fois que vous avez cette carte, remonter à la source côté WordPress devient plus rationnel, moins anxiogène, et surtout plus efficace.</p></x-turndown>