Sur WordPress, une redirection non autorisée ressemble souvent à une petite gêne. Une page qui charge ailleurs, un lien qui “marche” mais vers une destination étrange, parfois même une mise en avant publicitaire qui n’a aucun rapport avec votre site. Le problème, c’est que ces redirections sont rarement isolées. Elles peuvent servir à injecter du trafic, à voler des sessions, à dégrader le SEO, ou à masquer un accès compromis. Et quand cela passe par des plugins, la frontière entre “paramétrage” et “malveillance” devient vite floue.
J’ai vu plusieurs cas typiques. Un site e-commerce qui redirigeait discrètement vers une page de paiement ressemblant au site officiel d’un prestataire, mais avec des identifiants visiblement falsifiés. Un blog qui envoyait certains visiteurs vers une page “newsletter” dont le contenu changeait toutes les semaines, signe que l’origine du script n’était pas stable. Dans les deux cas, la source était un plugin installé ou modifié récemment, et la redirection apparaissait même après une simple purge de cache. Ce genre de comportement donne une piste, mais il faut vérifier sans se raconter d’histoire.
L’objectif de cette lecture est simple: identifier proprement les redirections, déterminer si elles viennent d’un plugin suspect ou d’une autre couche (thème, base de données, serveur), puis mettre en place une sécurisation WordPress réaliste, avec des contrôles qui ne demandent pas de compétences de forensic à chaque incident.
Pourquoi les redirections “bizarres” sont un signal d’alarme
WordPress peut rediriger pour des raisons légitimes. Un changement d’URL, une migration, un plugin de SEO, des règles de cache, ou même un CDN peuvent provoquer des sauts. Le danger, c’est quand la redirection n’a pas de logique métier et qu’elle touche seulement une partie des visiteurs ou certaines pages.
Dans les incidents liés à des plugins, les schémas reviennent souvent:
- redirection conditionnelle (uniquement pour certains pays, navigateurs, ou utilisateurs connectés) redirection “à heure fixe” (par exemple après une mise à jour ou à l’ouverture d’une fenêtre de maintenance) redirection vers des domaines de type lien sponsorisé, “offres”, “adult”, “cryptos”, ou pages qui imitent votre identité persistance: après désactivation du plugin, la redirection continue, ce qui indique que l’attaque a écrit ailleurs (options WordPress, base de données, fichiers de thème, règles serveur)
Le premier réflexe doit donc être de traiter la redirection comme un symptôme, pas comme un défaut isolé.
Cartographier le phénomène avant d’attaquer le code
Avant de supprimer quoi que ce soit, je recommande de comprendre exactement ce qui se passe. Sinon, vous risquez d’ôter le plugin “visible” sans régler la source “écrite”, et de replonger deux jours plus tard.
Concrètement, testez plusieurs scénarios:
Sur votre ordinateur, dans une session navigateur “propre” (navigation privée ou profil dédié). Sur un autre appareil ou au moins un autre réseau (mobile en 4G, par exemple). Sur plusieurs pages du site, pas seulement la page qui pose problème. Si possible, comparez un utilisateur connecté et un utilisateur anonyme.Si vous voyez des redirections qui varient selon le contexte, c’est encore plus compatible avec du code injecté ou des scripts conditionnels. Dans ce cas, les logs et les traces HTTP prennent de la valeur.
Côté technique, un point pratique aide beaucoup: observer l’enchaînement de redirections. https://gardewp.fr/securite-wordpress/ Par exemple, au lieu de dire “ça redirige vers un autre site”, notez la chaîne exacte: votre URL, puis éventuellement un domaine intermédiaire, puis la destination finale. Cette chaîne peut être révélatrice, notamment quand un plugin envoie vers un script “loader” puis vers un domaine final.
Outils simples pour repérer la source
Je ne vais pas promettre un outil magique qui “trouve le hack” en une commande. En revanche, il existe des approches assez directes.
Examiner les fichiers chargés et les points d’injection
Un plugin malveillant cherche souvent à exécuter du code au moment du chargement WordPress (via wp-config.php modifié, un fichier dans wp-content, un mu-plugin, ou un chargement conditionnel). Sans tomber dans la chasse au fichier au hasard, vous pouvez faire un repérage pragmatique:
- Vérifiez les fichiers récemment modifiés dans wp-content/plugins et wp-content/mu-plugins. Contrôlez la présence de fichiers inattendus dans wp-content (par exemple des dossiers ou scripts temporaires). Regardez les plugins “coupables” récemment installés, surtout s’ils n’ont pas de raison fonctionnelle sur votre site.
C’est souvent là que j’ai trouvé des surprises: un plugin “outil SEO” qui ne correspond à aucune fonctionnalité utilisée, ou un plugin “captcha” qui n’a aucun paramétrage côté interface mais qui injecte du code en arrière-plan.
Utiliser les logs et headers HTTP
Les redirections se lisent dans les headers HTTP. Si votre hébergeur propose des logs Nginx/Apache, cherchez les codes 301, 302, 307 ou 308 sur des URLs précises. Ensuite, reliez ces événements à une fenêtre temporelle: quelle mise à jour a eu lieu la veille, quel plugin a été installé, quel compte a tenté une action.
Même sans logs détaillés, votre navigateur peut vous donner des indices. Si vous utilisez un outil d’inspection réseau, vous verrez souvent l’origine de la redirection. L’idée est de savoir si la redirection est déclenchée côté application (WordPress renvoie un header depuis PHP) ou côté serveur (règles dans .htaccess, Nginx, ou configuration CDN).
Distinguer redirection côté WordPress, côté serveur, ou via un plugin
Beaucoup de gens commencent par désactiver le plugin. C’est parfois efficace, mais ce n’est pas toujours suffisant. Pour mieux cibler, posez-vous une question: la redirection se produit-elle après désactivation, et si oui, sur quelles URLs?
- Si la désactivation du plugin stoppe la redirection, la cause est probablement dans le code du plugin. Si la redirection continue, il peut rester des traces ailleurs: un fichier modifié dans le thème, une entrée en base de données, une règle serveur, ou un plugin qui reste actif mais qui n’est pas celui que vous pensiez. Si la redirection touche des “pages” plutôt que tout le site, pensez à un mécanisme d’URL rewriting, un plugin SEO, ou une règle de cache.
Un détail qui m’a aidé dans un incident récent: la redirection ne concernait que les articles d’une catégorie. En inspectant la base de données, la logique semblait basée sur des identifiants de pages ou des slug changés. Le plugin malveillant n’“arrosait” pas tout, il ciblait un sous-ensemble. Sans test multi-pages, l’enquête aurait tourné court.
Cas fréquents de plugins suspects et comment les reconnaître
Tous les plugins “suspects” ne sont pas forcément malveillants. Un plugin peut aussi être mal configuré, ou en conflit avec un autre. Mais certains signaux doivent vous faire ralentir et inspecter sérieusement.
Voici quelques indices concrets, observés sur plusieurs incidents:
- le plugin n’est pas nécessaire au fonctionnement du site (au-delà d’un essai abandonné) le plugin a été modifié récemment, alors que vous ne l’avez pas fait le plugin charge des scripts externes inconnus, ou fait des appels réseau inhabituels le plugin crée des options en base ou enregistre des hooks sans configuration claire le plugin tente de masquer son activité via des structures obscures, et injecte du code dans des zones attendues (par exemple dans le contenu avant affichage)
Notez qu’un plugin peut paraître normal, mais intégrer une petite portion de code qui fait basculer certains visiteurs. La malveillance sur WordPress est souvent “petite”, et donc facile à rater si on ne regarde pas le comportement réel.
Vérifier ce que fait vraiment un plugin
Je privilégie une approche progressive: observation, isolation, puis suppression ou remplacement.
La méthode la plus saine est de tester l’état du site avec un nombre minimal de variables. Si votre site permet un mode de maintenance ou un environnement de staging, c’est encore mieux. Sinon, vous pouvez procéder directement sur la production, mais avec prudence.
L’idée: neutraliser l’impact sans casser le site, puis observer si la redirection disparaît.
Un plan d’action concret en environnement de test
Si vous avez une copie (staging ou backup), utilisez-la. C’est là que vous pouvez ouvrir le code et regarder les hooks, sans stress.
Voici l’ordre de travail que j’utilise le plus souvent quand je dois gérer des redirections non autorisées:
Identifier le plugin le plus récent ou le plus “non expliqué” dans la période d’apparition. Couper temporairement le plugin et vérifier la redirection sur plusieurs URLs. Si la redirection continue, désactiver les plugins additionnels apparents, puis chercher ailleurs (thème, base de données, règles serveur). Une fois la source trouvée, supprimer le plugin et nettoyer les traces persistantes.Je sais que la tentation est de “tout supprimer”. Ce serait plus simple, mais c’est risqué sur un site vivant. En pratique, l’objectif est de garder le site accessible tout en réduisant la surface d’attaque.
Checklist de diagnostic (sans tout casser)
Vous pouvez suivre cette mini grille quand vous cherchez l’origine d’une redirection liée à un plugin:
- La redirection ne se produit-elle que pour certains visiteurs ou pour tout le monde. Le problème apparaît-il après désactivation d’un plugin suspect. La destination redirigée change-t-elle selon l’URL ou selon l’heure. Le serveur renvoie-t-il des codes 301/302 depuis PHP, ou depuis des règles de configuration. Le plugin modifie-t-il des options ou des fichiers “en dehors de son dossier”.
Ces cinq points suffisent souvent à orienter l’analyse. Si au moins deux réponses sont cohérentes, vous avez déjà un bon niveau de confiance.
Nettoyer après la suppression: la partie que beaucoup ratent
Un piège fréquent: vous désinstallez le plugin suspect, et la redirection revient après. Pourquoi? Parce que l’attaque n’était pas seulement dans le plugin. Elle peut avoir:
- ajouté des entrées dans la base de données (options, shortcodes, métadonnées) modifié un fichier dans le thème, parfois juste quelques lignes écrit un fichier dans wp-content ailleurs que dans le dossier du plugin ajouté une redirection via les règles serveur (par exemple dans .htaccess ou une config de reverse proxy) laissé un plugin “miroir” dans mu-plugins qui recharge du code au démarrage
La suppression du plugin ne supprime pas toujours tout ce qui a été modifié pendant l’incident. Donc, même quand vous identifiez le plugin, prévoyez un nettoyage plus large que la seule suppression.
Restaurer les fichiers de base
Si vous avez un accès à une copie saine (backup propre), comparez les fichiers WordPress et du thème. La plupart du temps, vous n’avez pas besoin de comparer fichier par fichier à la main, mais vous devez au moins vérifier les fichiers à fort impact:
- wp-config.php (attention aux constantes et aux chemins, toute modification inattendue doit alerter) le thème actif et le parent si thème enfant (surtout les fichiers qui ajoutent du contenu ou gèrent les hooks) le dossier wp-content/uploads si vous avez des scripts cachés ou des fichiers anormaux
Je préfère remplacer ou restaurer les éléments depuis une source fiable plutôt que de supprimer “à la ligne”. On peut gagner du temps, mais on peut aussi supprimer un morceau de configuration légitime si on se trompe.
Sécuriser l’accès: empêcher le retour
Un incident de redirection via plugins suspects n’arrive pas par hasard. Il arrive parce que quelqu’un a réussi à introduire ou activer du code. La sécurisation WordPress ne se limite donc pas au nettoyage, elle vise l’accès et la capacité d’écriture.
Quelques actions pratiques sont souvent plus efficaces que multiplier les plugins de “sécurité”:
- Révoquer les sessions et changer les mots de passe des comptes ayant un rôle élevé. Vérifier l’activité des comptes et les nouveaux utilisateurs créés. Contrôler les événements d’accès, surtout les tentatives répétées vers wp-admin. Réduire les droits, limiter les comptes admin au strict nécessaire.
J’ai déjà vu un site où le plugin suspect était “juste” l’arme du moment. La vraie faille venait d’un mot de passe recyclé sur plusieurs services. Tant que le compte n’était pas nettoyé, le plugin revenait après chaque correction.
Mettre un garde-fou contre les redirections futures
Une fois le nettoyage fait, l’étape qui m’évappe le moins en valeur, c’est de mettre en place une surveillance simple. Sur WordPress, vous voulez une détection assez tôt pour intervenir avant que le SEO et la réputation ne prennent cher.
Cela passe souvent par:
- des règles de surveillance d’intégrité (fichiers modifiés) l’alerte sur l’installation de plugins ou la modification de thèmes un contrôle régulier des redirections visibles pour une liste d’URLs critiques
Il ne s’agit pas de scanner toutes les minutes, mais de créer une cadence que vous pouvez tenir. Dans un site géré “à la main”, la surveillance hebdomadaire sur des points clés est déjà un progrès énorme.
Voici une petite liste d’URLs et de comportements à observer, à adapter à votre site:
- votre page d’accueil depuis navigation privée une page de catégorie ou une page archive un article récent et un ancien le formulaire de connexion ou un parcours utilisateur sensible
Si une redirection apparaît ici, vous savez que ce n’est pas un bug SEO isolé.
Et si le plugin n’est pas le seul responsable?
Parfois, le plugin n’est que le déclencheur, et la redirection vient d’ailleurs. Les redirections peuvent être gérées par le thème, par des réglages d’URL dans des plugins SEO, par un CDN, ou par des règles serveur.
Un exemple classique: un plugin de cache ou d’optimisation peut injecter des headers ou modifier la mise en cache. Il peut provoquer des redirections temporaires si les règles sont mal coordonnées. Dans ce cas, vous verrez des comportements cohérents avec la configuration: par exemple, toujours la même logique de redirection, sans changement aléatoire de destination.
C’est pour ça que je reviens toujours à l’analyse en chaîne de redirection et au test “multi-sessions”. Si tout est identique en navigation privée sur plusieurs pages, on n’est pas forcément face à une malveillance. Si la destination varie ou si des scripts tiers apparaissent, la prudence est de mise.
Cas pratique: une redirection ciblée après une mise à jour plugin
Je vous raconte une histoire assez typique, sans rentrer dans des détails de marque ou des URL exactes. Un site vitrine avait subi une mise à jour d’un plugin “media” et, deux jours après, certaines personnes recevaient une redirection vers une page d’actualités étrangères. Le site n’avait pas de raison de pointer vers ces contenus.
Ce qui a été décisif:
- La redirection ne touchait pas tout le monde. Un test en navigation privée montrait le problème uniquement sur des navigateurs spécifiques. Les headers de réponse indiquaient une redirection HTTP déclenchée par PHP, pas une règle serveur. En regardant l’historique, c’était précisément la période d’installation et de mise à jour du plugin.
Le nettoyage a demandé plus que la suppression du plugin. Il y avait aussi une entrée dans la base, une option stockée avec un callback déclenché à l’affichage de certaines pages. Une désactivation a interrompu une partie, mais la redirection revenait quand la page utilisait un shortcode ajouté à l’insu.
Après restauration partielle, purge des caches, puis suppression totale du plugin, la redirection a cessé.
Ce cas illustre la logique suivante: une attaque peut être “modulaire”. Elle pose une couche de déclenchement, et elle stocke la destination dans des paramètres. Donc, si vous ne nettoyez que la couche visible, vous ne fermez pas le robinet.
Erreurs à éviter pendant l’intervention
Quand on gère une redirection non autorisée, certaines erreurs reviennent. Elles ne sont pas spectaculaires, mais elles coûtent du temps.
D’abord, croire qu’une purge de cache suffit. Si la redirection est renvoyée par PHP, le cache ne fait que répéter une réponse. Ensuite, supprimer uniquement le plugin sans vérifier .htaccess, la configuration du serveur ou le thème.
Autre erreur fréquente: remplacer rapidement le plugin par un autre sans comprendre la cause d’installation. Si le compte admin à l’origine de l’installation est compromis, vous réparerez un symptôme pendant un moment, puis l’incident reviendra.
Enfin, laisser le site accessible au public pendant l’enquête. Quand vous suspectez une activité malveillante, mieux vaut mettre le site en maintenance le temps de couper la source, surtout si des redirections vers des domaines externes sont en jeu. En pratique, quelques heures de maintenance valent mieux que des pages de redirection indexées.
Une démarche de sécurisation WordPress qui tient dans la durée
Après avoir géré l’incident, je conseille de formaliser une routine. Pas forcément lourde, mais régulière.
Le point clé, c’est la cohérence entre quatre axes: accès, intégrité, détection, et hygiène de plugins.
- Accès: mots de passe uniques, contrôle des rôles, limitation des comptes. Intégrité: vérification des fichiers modifiés et restauration depuis une base saine si besoin. Détection: surveillance d’URLs sensibles et alerte sur changements (plugins, thèmes). Hygiène: supprimer ce qui n’est pas utile, éviter d’empiler des plugins dont vous ne maîtrisez pas les hooks.
Cette approche réduit la probabilité que la prochaine redirection non autorisée vous surprenne.
Choisir entre “réparer” et “réinstaller” le sujet
Sur WordPress, il arrive qu’une reconstruction complète soit plus simple qu’une réparation fine, surtout quand vous suspectez une intrusion profonde. Si plusieurs composants sont modifiés, si vous n’avez pas de backup avant incident, et si vous voyez des comportements inconsistants, une réinstallation propre peut être la décision la plus rentable.
Le compromis se situe dans vos données et votre configuration. On peut réinstaller WordPress, restaurer les thèmes depuis sources fiables, puis réimporter uniquement la configuration nécessaire. Mais il faut alors être prudent sur la récupération de la base. Si la base contient des options injectées, les réinstaller aussi revient à remettre le poison.
Dans ces cas, la stratégie consiste à restaurer proprement tout ce qui doit l’être, puis à rétablir progressivement, en contrôlant à chaque étape l’apparition de la redirection.
Points de contrôle rapides après incident
Une fois le nettoyage terminé, ne vous contentez pas de vérifier une page. WordPress est un système de hooks, donc un détail peut passer inaperçu pendant une journée.
Voici ce que vous devriez vérifier rapidement, en pratique:
- aucune redirection vers des domaines inconnus, depuis navigation privée les pages clés (accueil, article, connexion, pages de paiement si applicable) ne changent pas de destination l’historique des plugins et thèmes ne montre pas de nouveaux ajouts non expliqués la base ne contient pas d’options ou shortcodes suspects déclenchés à l’affichage le serveur et .htaccess n’ont pas de règles de redirection ajoutées pendant la période d’incident
Si tout ça est propre, vous avez un bon niveau de confiance, même s’il reste toujours une part d’incertitude à cause de certains mécanismes dynamiques.
Dernier conseil: travailler avec une trace
Quand vous avez un incident, gardez des traces. Un simple dossier texte peut suffire: dates, plugins installés, comportement observé, URLs impactées, captures de redirection, et résultats des tests.
Ce dossier aide pendant le nettoyage, mais il aide surtout pour éviter la répétition. Si vous devez revenir sur l’incident dans un mois, vous saurez exactement ce que vous avez fait, et ce que vous pensiez avoir corrigé.
Les redirections non autorisées sont souvent un symptôme visible d’une intrusion plus large. Les corriger demande de regarder au bon endroit, pas seulement de supprimer le plugin le plus “visible”. Avec une démarche structurée, des tests multi-sessions, et un nettoyage qui dépasse la suppression, vous pouvez remonter à la source et remettre votre site dans un état fiable. C’est là que la sécurisation WordPress devient autre chose qu’une liste de plugins, un vrai processus.