Quand on parle de sécurité WordPress, on pense souvent à la connexion, aux mots de passe, aux mises à jour. C’est logique, mais la fraude se cache parfois dans des endroits plus discrets: des pages “utiles” qui deviennent des appâts, des redirections qui finissent sur un domaine malveillant, ou des formulaires qui déclenchent des comportements inattendus. Le résultat est rarement spectaculaire au début. C’est plutôt une série de détails: un lien interne qui n’a plus le bon chemin, un bouton qui change de cible, un formulaire qui renvoie vers une page “d’attente” qui n’attend rien.
Dans cet article, je vais me concentrer sur deux zones que je vois revenir dans les incidents: la sécurité des pages (contenu, accès, formulaires) et la sécurité des redirections (liens, URL, redirections 301/302, plugins et codes). L’objectif n’est pas de promettre une immunité totale, mais de réduire fortement la surface d’attaque et de rendre les comportements frauduleux plus difficiles, plus visibles, et surtout plus simples à diagnostiquer.
Les scénarios de fraude les plus fréquents autour des pages et des redirections
Une attaque contre WordPress vise rarement “juste” à injecter un message. Le plus souvent, elle cherche à orienter une victime, collecter quelque chose, ou faire croire à une action légitime. Les redirections sont parfaites pour ça, parce qu’elles peuvent rester discrètes: l’utilisateur croit qu’il visite votre site, puis il est guidé ailleurs.
Trois scénarios reviennent souvent dans les audits et les reprises de maîtrise après incident.
D’abord, la page “de transition”. L’attaquant ajoute ou modifie une page qui ressemble à une page d’information, un avis, un tracking, une vérification. Le texte peut être propre, même cohérent, mais le comportement derrière la page ne l’est plus. Par exemple, la page peut lancer un script au chargement, déclencher une redirection côté navigateur, ou appeler un endpoint qui collecte des cookies ou des identifiants.
Ensuite, la redirection non maîtrisée. On voit parfois des liens internes modifiés, soit dans le contenu, soit dans les menus, soit via des champs de configuration d’un plugin. Le plus piégeux, c’est quand la redirection fonctionne “par moments”: selon la géolocalisation, le User-Agent, ou l’heure. Dans ces cas, les tests manuels passent, jusqu’au jour où un utilisateur réel tombe sur la variante frauduleuse.
Enfin, l’abus des formulaires et des pages “action”. Des formulaires simples (contact, newsletter, prise de rendez-vous) peuvent être détournés. Par exemple, on peut modifier l’URL de destination, ou injecter un paramètre dans l’action qui change la cible après validation. L’attaquant profite du fait que la victime accepte le comportement attendu: remplir un formulaire, puis être redirigé.
Ce qui relie ces scénarios, c’est le contrôle. Quand vous ne contrôlez plus strictement ce qui affiche une page et ce qui arrive ensuite via une redirection, vous perdez un filet de sécurité. Et en sécurité WordPress, ce filet manque rarement d’importance.
Sécuriser les pages: empêcher les modifications “qui semblent légères”
La première défense, c’est de traiter chaque page comme une surface d’attaque. Pas seulement parce qu’elle pourrait contenir du code, mais parce qu’elle peut déclencher des redirections, appeler des ressources externes, ou servir de relais.
Restreindre ce qui peut être modifié, et par qui
Un site WordPress avec trop de rôles “contributeur”, ou trop de comptes qui ont accès aux pages sensibles, finit toujours par payer. Une fraude commence souvent par un accès. L’accès n’a pas forcément besoin d’être administrateur. Dans certains cas, un rôle trop permissif peut suffire à modifier un template, un champ, un shortcode, ou un script dans une zone “réutilisable”.
Concrètement, je recommande de revoir la gouvernance des comptes: limiter l’accès aux pages qui servent de portes d’entrée (connexion, compte, paiement, confirmation, redirections), et exiger une justification claire pour chaque personne qui a un accès éditorial.
Verrouiller le contenu réutilisable et les templates
Le piège classique, ce sont les blocs réutilisables, les templates, et les parties de thème. Un attaquant peut injecter une logique dans un endroit qui n’attire pas l’œil. Par exemple, un template d’archive, ou une partie de header qui n’est jamais relue.
Le bon réflexe, c’est de vérifier ce qui est injecté avant le contenu principal. Regardez les fichiers du thème et les fichiers de configuration qui pilotent les redirections ou les scripts. Si vous utilisez des thèmes enfant, assurez-vous que le code malveillant n’a pas migré dans l’un des deux.
Détecter les injections discrètes dans le HTML et les shortcodes
Les injections frauduleuses dans WordPress ont parfois un style “propre”: elles utilisent des conditions simples, des variables globales, ou des sélecteurs de manière à éviter de casser le rendu. Sur le plan opérationnel, je conseille une approche de détection plutôt qu’une lecture “au cas par cas”.
Vous pouvez, par exemple, surveiller les patterns dans les pages qui changent le plus: présence de JavaScript inattendu, balises iframe, https://gardewp.fr/securite-wordpress/ appels à des domaines externes non déclarés, redirections via métas refresh, ou scripts chargés depuis des CDN inconnus. Quand je diagnostique, je commence souvent par comparer le code source d’une page “saine” à celui d’une page suspecte, sans me limiter au contenu affiché.
Et oui, les shortcodes sont à surveiller. Un shortcode peut générer une URL, et cette URL peut déclencher une redirection. Si un shortcode “inoffensif” a été modifié, il peut devenir un pont vers une fraude.
Sécuriser les redirections: ce qui doit rester sous contrôle
Les redirections sont le moment où la confiance bascule. L’utilisateur arrive sur votre site, puis il est emmené ailleurs. Du point de vue de la fraude, c’est une opportunité majeure.
Mais tout n’est pas noir ou blanc. Une redirection peut être légitime, par exemple pour une migration de contenu, un changement d’URL, ou une logique de langue. La question est la suivante: est-ce que vous contrôlez strictement la destination et les règles de redirection ?
Éviter les redirections basées sur des entrées non validées
Beaucoup de redirections frauduleuses exploitent des paramètres d’URL. Typiquement, un site utilise un paramètre comme ?next=... ou ?redirect=.... Si la valeur n’est pas validée, l’attaquant peut fournir une destination externe, et la page peut vous servir de relais.
Même si votre site ne fait pas explicitement ce genre de chose, certains plugins peuvent le faire. Il faut donc traiter les paramètres de redirection comme des données non fiables.
La règle pratique est simple: n’acceptez pas de destination arbitraire. Autorisez uniquement des destinations internes, ou utilisez une liste blanche. En sécurité WordPress, ce contrôle de flux est souvent plus efficace que de “nettoyer” a posteriori.
Vérifier les redirections via le serveur, le plugin, et le code
Les redirections peuvent être définies à plusieurs niveaux.
Au niveau serveur, il peut y avoir des règles dans .htaccess ou dans votre configuration Nginx. Un incident peut ajouter une règle trop permissive, ou une condition qui renvoie vers une destination externe selon des critères vagues.
Au niveau WordPress, un plugin de redirection peut exister, même s’il n’est pas censé être utilisé. Il peut être configuré pour rediriger certaines pages vers des destinations malveillantes, ou pour effectuer des variantes selon l’environnement.
Au niveau application, des fonctions peuvent appeler wp_redirect() avec des paramètres, ou des scripts JavaScript peuvent rediriger côté client. Quand vous cherchez une fraude, vous voulez voir les trois couches, parce qu’une partie de l’incident peut n’apparaître que dans une seule.
Surveiller l’usage des statuts 301 et 302, et les pages d’erreur
Un autre angle utile est l’observation des codes HTTP. En fraude, on peut “préférer” certains comportements, par exemple garder la navigation fluide. Une redirection 302 peut donner l’impression que tout est temporaire, et une 301 peut ancrer le comportement en caches (y compris côté navigateur).
En parallèle, une page d’erreur modifiée peut aussi rediriger. Les attaques peuvent exploiter 404 et 500 pour orienter des utilisateurs vers une destination externe. Si votre site renvoie une 404 “propre” avec une redirection cachée, la fraude s’incruste sans déclencher d’alarmes immédiates.
Rendre les pages sensibles moins “faciles” à utiliser comme appâts
Certaines pages sont des aimants. Les pages d’authentification, de compte, de paiement, de confirmation de commande, de réinitialisation de mot de passe, et même certaines pages de “mise à jour” peuvent attirer des attaques.
L’approche à adopter consiste moins à “empêcher tout contenu” qu’à réduire les chemins d’exploitation.
Protéger les points d’entrée
Quand une page sert d’entrée, elle doit rester stable, et son comportement doit être cohérent. Par exemple, une page de réinitialisation doit toujours exécuter la logique attendue, puis rediriger vers une page interne. Si vous constatez une redirection vers un domaine externe, c’est généralement un drapeau rouge.
Pareil pour les pages de confirmation. Si un utilisateur reçoit “vous allez être redirigé” vers une URL étrange, vous devez vérifier la source de cette URL. Souvent, le problème vient d’un paramètre injecté, d’un champ modifié dans un plugin, ou d’un script ajouté dans une page.
Mettre un contrôle sur les liens sortants
Même une page d’information peut contenir des liens sortants. Ce n’est pas forcément malveillant, mais une fraude peut transformer un lien neutre en rampe de lancement, surtout si la destination dépend d’un paramètre.
Si vous avez des liens sortants, gardez une trace claire de leur origine, et évitez les redirections externes générées automatiquement à partir de données utilisateur. Le risque augmente si vous acceptez des URL dans des champs que vos visiteurs peuvent influencer, même indirectement.
Une méthode de vérification simple quand vous suspectez une redirection frauduleuse
Il y a une différence entre “je pense” et “je sais”. Dans les investigations que j’ai menées, la meilleure aide vient d’un protocole court, reproductible, qui évite de confondre un bug légitime et une fraude.
Je propose une routine en quatre temps. Elle n’est pas une procédure officielle universelle, mais elle m’a plusieurs fois évité de perdre une journée entière.
1) Repérez l’URL exacte, puis testez depuis une session propre
Notez l’URL qui pose problème, y compris le chemin, les paramètres, et l’ordre des paramètres. Testez ensuite depuis une session sans cookie (navigation privée) et, si possible, depuis un autre réseau. Les fraudes conditionnelles aiment certains contextes.2) Inspectez le HTML de la page avant tout rendu “apparent”
Dans le code source, cherchez des éléments qui déclenchent des actions sans être visibles. Métas refresh, scripts avec chargement de fichiers externes, iframes, ou liens “cachés” peuvent pointer vers une destination.3) Tracez le chemin de la redirection côté serveur
Si vous avez accès à des logs (serveur, application, CDN), cherchez les entrées qui correspondent à la requête. Vous voulez savoir si la redirection vient du serveur (301/302), d’un plugin, ou d’un script côté navigateur. 
4) Contrôlez les règles de redirection et les points de configuration
Vérifiez les règles du plugin de redirection s’il existe, puis contrôlez les fichiers d’options ou de configuration qui peuvent exister. Si une règle redirige vers un domaine externe, vous avez le cœur du problème.Cette routine est volontairement “pratique”. Elle vous guide sans exiger une lecture exhaustive de tout le site, ce qui serait souvent contre-productif.
Durcir WordPress contre les redirections injectées par plugins et thèmes
Les redirections sont parfois “cachées” dans des endroits que l’on ne surveille pas. C’est là que la stratégie de durcissement devient utile: réduire la possibilité d’ajouter des règles ou du code, et augmenter la visibilité quand quelque chose change.
Limiter les plugins et empêcher les modifications inattendues
Un site qui a beaucoup de plugins, avec des mises à jour rares, devient difficile à auditer. Chaque plugin peut ajouter son propre mécanisme de redirection ou de réécriture.
En pratique, je vise deux choses: supprimer ce qui n’est pas indispensable, et surveiller les plugins qui touchent à l’URL (redirections, SEO, cache, sécurité, performance). Ensuite, je vérifie que les plugins sensibles ont bien les limites attendues, par exemple une interface cohérente et des destinations internes.
Mettre en place une discipline de modification
La fraude se propage souvent pendant des changements. Un déploiement, un changement de thème, une mise à jour d’un plugin, puis soudain des redirections apparaissent.
Je recommande de coupler vos modifications à un “avant/après” simple: sauvegarde, export de paramètres de redirection si vous en utilisez, et capture des pages sensibles avant déploiement. Si un incident arrive, vous gagnez un temps énorme.
Exemple concret: une redirection qui ne se déclenche pas toujours
Un cas que j’ai vu récemment: une redirection frauduleuse ne touchait pas tout le monde. Sur une équipe, deux personnes sur dix ont été redirigées vers une page externe après un clic sur un bouton de “suivi de commande”. Les autres n’avaient rien remarqué.
Le premier réflexe aurait été de chercher dans la page visible. Mauvaise piste. La page elle-même affichait un bouton propre, sans code suspect visible. Le déclencheur était un paramètre construit par JavaScript à partir de données présentes dans le navigateur. Selon la session et les cookies, la destination changeait.
Le diagnostic a été accéléré par deux contrôles: comparer le code source de la page sur les deux sessions (celle qui échoue et celle qui ne fait rien), puis observer les requêtes réseau au moment du clic. Une fois la destination identifiée, on a retrouvé la source dans un champ de configuration d’un plugin, avec une valeur qui contenait un domaine externe encodé.
Cette histoire illustre un point important: le fait que “ça marche pour certains” ne veut pas dire que “c’est normal”. Les fraudes aiment la variabilité.
Liste courte de priorités si vous voulez sécuriser sans tout casser
Voici une liste de priorités que je mets en place quand un client veut réduire le risque sans arrêter le site. Elle tient volontairement en peu de points, parce que l’objectif est d’être actionnable.
- Réduire les rôles capables de modifier des pages sensibles, et journaliser les changements de contenu Désactiver temporairement les plugins qui touchent aux redirections ou à l’URL, puis tester les flux critiques Vérifier les règles de redirection côté serveur (si accès à .htaccess ou configuration équivalente) Mettre une validation stricte pour toute redirection basée sur paramètres d’URL, avec liste blanche interne Surveiller les domaines externes chargés par des pages clés et alerter si une origine change
Ces actions sont souvent suffisantes pour interrompre un scénario de fraude. Et elles laissent une base de diagnostic.
Conseils pour garder le contrôle dans la durée
La sécurité n’est pas un sprint, surtout quand WordPress et son écosystème bougent. Le but, c’est d’empêcher la fraude de se maintenir discrètement, et de rendre les changements exploitables rapidement détectables.
Tenir un inventaire simple de ce qui redirige
Je conseille de documenter, même brièvement, ce qui gère vos redirections: plugin de redirection, règles serveur, logique interne (exemples: redirection de langue, redirection post-login). Quand vous le faites, vous réduisez les angles morts.
Si vous ne savez pas aujourd’hui où se trouvent vos redirections, vous ne pourrez pas prouver qu’elles sont “sous contrôle” en cas d’incident.
Surveiller les changements de fichiers et les pages “hors routine”
Dans la fraude, il y a une différence entre “un nouveau contenu normal” et “une page qui change sans raison”. Les pages qui servent à la conversion ou aux actions sensibles doivent être stables.
Je surveille aussi les fichiers de thème et les fichiers de plugins. Une modification non planifiée est rare sur un site sain, même si elle peut arriver suite à une mise à jour. D’où l’intérêt de garder des jalons de déploiement.
Réagir avec un plan de remédiation clair
Quand on découvre une redirection frauduleuse, il faut agir vite, mais pas à l’aveugle. Si vous coupez le site entièrement, vous perdez peut-être l’accès aux logs. Si vous changez tout sans isoler, vous risquez de casser la reconstruction.
L’approche la plus utile consiste à identifier d’abord la source de redirection, puis à la neutraliser de manière ciblée. Ensuite seulement, vous remettez en ordre thèmes, plugins, et configurations.
Cas limites qui piègent les bonnes intentions
Il y a des situations où la redirection “semble” malveillante, alors qu’elle est légitime. À l’inverse, des comportements légitimes peuvent faciliter une fraude.
Voici quelques cas qui méritent un jugement.
- Redirection liée à la langue ou à un A/B test: si vous utilisez un CDN ou un test marketing, certaines redirections peuvent varier selon le User-Agent Redirections de cache côté CDN: un ancien cache peut renvoyer vers une destination déjà obsolète, puis revenir à la normale URL mal encodées: une page qui construit une URL avec des caractères spéciaux peut sembler “sortir du domaine”, alors que c’est juste un bug Changement de nom de domaine ou migration SEO: certaines règles 301 sont attendues, mais elles doivent rester internes et maîtrisées Redirections après connexion: si vous utilisez un paramètre de retour, la validation interne est indispensable
Dans ces cas, il faut comparer. Une fraude en général introduit un domaine externe, une origine non attendue, ou un comportement trop conditionnel. Un bug légitime, lui, tend à être reproductible et cohérent avec votre logique.
Comment je vérifie que les pages et les redirections sont vraiment “sous contrôle”
Quand je fais une vérification, je ne m’arrête pas à “ça a l’air OK”. Je veux un contrôle qui résiste au doute. Pour ça, je regarde trois choses en parallèle.
D’abord la cohérence des flux: de la page d’entrée vers la destination finale. Ensuite la source de vérité: est-ce que la redirection est imposée par WordPress, par le serveur, ou par un script ? Enfin, la stabilité: est-ce que le comportement se répète de manière identique selon une session propre et une session “réelle”.
C’est souvent cette triple lecture qui donne confiance. Une redirection qui change de logique selon les sessions ou les paramètres, sans explication fonctionnelle, est un signal fort.
Ce qu’il faut retenir
Sécuriser les pages et les redirections contre la fraude, ce n’est pas seulement “empêcher d’écrire du code”. C’est surtout retrouver le contrôle sur le chemin de l’utilisateur. Une page frauduleuse peut être une simple étape, mais une redirection mal maîtrisée peut transformer une visite normale en incident.
Si vous gardez cette idée en tête, les choix deviennent plus clairs: limiter les rôles, surveiller les points de modification, valider strictement les destinations de redirection, et documenter ce qui gère vos URL. C’est moins glamour qu’une liste de mesures “techniques”, mais c’est ce qui protège réellement au quotidien, quand une modification non planifiée ou une injection discrète tente de s’installer.