12 questions sur la Sécurité WordPress posées à un expert, Thierry Pigot.

WordPress alimente aujourd’hui plus de 40% du web. Avec cette popularité on peut se poser une question : la sécurité WordPress est-elle fiable ?

Aujourd’hui je donne la parole à Thierry Pigot, expert en sécurité WordPress.

Je lui ai posé 12 questions. L’interview se termine avec des cas concrets.

Thierry Pigot travaille avec WordPress depuis 2005, d’abord comme développeur, puis très vite sur les sujets de maintenance, de support et de fiabilité des sites. Avec le temps, la sécurité est devenue un axe central de son activité, non pas par spécialisation opportuniste, mais parce qu’elle s’imposait sur le terrain.

WP Assistance est née de cette réalité : pour Thierry, un site WordPress n’est jamais “terminé”. Il vit, évolue, se met à jour, et doit être surveillé. La sécurité n’est donc pas un état, mais un travail continu, souvent invisible, toujours nécessaire.

Depuis combien de temps travailles-tu sur la sécurité des sites WordPress ?

Si l’on parle strictement de sécurité, cela fait environ quinze ans.
Mais dans les faits, la frontière entre maintenance et sécurité est mince. Dès lors que l’on gère des mises à jour, des sauvegardes, des incidents ou des restaurations après problème, on touche déjà à des enjeux de protection.

Avec la généralisation des attaques automatisées, l’émergence de l’IA et un contexte géopolitique plus tendu, la sécurité est devenue un sujet structurant, et non plus un simple « plus » technique.

Quelle est, selon toi, la plus grande idée reçue sur la sécurité WordPress ?

L’idée que WordPress serait intrinsèquement peu sûr.
C’est une affirmation qui revient souvent, et qui repose surtout sur une confusion.

Le cœur de WordPress est globalement robuste. Il est audité, maintenu, corrigé rapidement lorsqu’une vulnérabilité est identifiée. Dans la très grande majorité des cas que nous traitons, le problème ne vient pas du CMS lui-même, mais de ce qui l’entoure.

D’où viennent la majorité des failles de sécurité sur WordPress ?

Elles proviennent principalement des extensions, puis des thèmes.
C’est logique : ce sont des briques de code ajoutées, parfois développées par de petites équipes, parfois abandonnées, parfois mal maintenues. Leur caractère open-source rend le code accessible, ce qui facilite l’analyse et la détection de failles, aussi bien par la communauté que par des attaquants.

Il faut aussi mentionner un point généralement sous-estimé : les configurations serveur inadaptées. Un site peut être parfaitement à jour côté WordPress, mais rester vulnérable si l’environnement d’hébergement laisse passer certaines attaques ou expose inutilement des ressources sensibles.

Pourquoi la provenance des thèmes et des extensions est-elle déterminante ?

Parce que la sécurité dépend directement de la qualité du code et du suivi dans le temps.
Une extension maintenue, documentée, mise à jour régulièrement et issue d’une source identifiée présente beaucoup moins de risques qu’un composant récupéré sans réel contrôle.

Dans les cas de piratage que nous analysons, il n’est pas rare de retrouver des extensions abandonnées depuis plusieurs années, ou des thèmes modifiés dont l’origine est floue.

Est-ce que des failles peuvent rester invisibles pendant longtemps ?

Oui, et c’est même assez fréquent.
Certaines vulnérabilités n’ont aucun impact visible tant qu’elles ne sont pas exploitées. Le site fonctionne normalement, sans message d’erreur, sans comportement suspect apparent.

Cela crée un faux sentiment de sécurité, alors que le problème est bien présent.

Certaines failles peuvent-elles rester « endormies » avant de se déclencher ?

C’est exact.
Il existe des mécanismes où du code malveillant ou une porte dérobée reste inactive jusqu’à ce qu’une condition précise soit remplie : un type de requête, un paramètre particulier, parfois même une date.

C’est l’une des raisons pour lesquelles certains piratages semblent “tomber du ciel”, alors que l’infection initiale est parfois ancienne.

Mises à jour automatiques ou gestion manuelle ?

Les deux ont leur place.
Les mises à jour automatiques du cœur WordPress et des correctifs de sécurité permettent de réduire fortement les délais d’exposition aux failles connues. C’est un point positif.

Pour les extensions plus sensibles ou critiques pour l’activité du site, une gestion supervisée reste préférable. Elle permet de tester, de vérifier les compatibilités et d’éviter des effets de bord.

Que sont les attaques par force brute ?

Il s’agit de tentatives automatisées visant à deviner des identifiants de connexion en testant un grand nombre de combinaisons.
Ces attaques sont simples, mais efficaces lorsque les mots de passe sont faibles ou lorsqu’aucune limitation n’est en place.

Les mesures de protection sont connues : limitation des tentatives, mots de passe robustes, authentification à deux facteurs, filtrage côté serveur.

Certaines protections doivent-elles être prises en charge par l’hébergement ?

Oui, clairement.
Certaines défenses sont bien plus efficaces lorsqu’elles sont mises en œuvre au niveau serveur : filtrage des requêtes, pare-feu applicatif, limitation des accès, protection contre certaines attaques automatisées.

Les extensions WordPress ont leur utilité, mais elles interviennent trop tard dans la chaîne si le serveur laisse passer des flux malveillants.

Que préconises-tu pour sécuriser correctement un site WordPress ?

Une approche cohérente, pas une accumulation d’outils.
Un hébergement sérieux, des extensions choisies avec discernement, des mises à jour suivies, des sauvegardes fiables et testées, et une surveillance régulière.

La sécurité n’est pas un produit que l’on installe une fois. C’est une discipline.

Si tu devais retenir seulement trois bonnes pratiques, lesquelles conseillerais-tu ?

1. Maintenir l’ensemble du site à jour.
2. Limiter strictement le nombre d’extensions utilisées.
3. Mettre en place des sauvegardes automatiques, avec des tests de restauration.

Ces trois points couvrent déjà une grande partie des risques courants.

Quels sont les signes d’un site WordPress piraté ?

Ils peuvent être évidents : redirections vers des sites tiers, messages d’alerte des navigateurs, contenus modifiés ou comptes administrateurs inconnus.

Ils peuvent aussi être beaucoup plus discrets, et donc plus dangereux. Une augmentation soudaine et inexpliquée du nombre de pages détectées dans la Search Console de Google, par exemple. On y découvre parfois des centaines, voire des milliers d’URL qui n’ont jamais été créées volontairement : pages de spam, contenus parasites, faux catalogues produits.

Autre signal très parlant : des liens injectés à des fins SEO, invisibles pour l’internaute, mais bien présents dans le code ou des envois d’e-mails inhabituels depuis le site.

Mais la plupart du temps, il n’y a aucun signe immédiatement visible. Le site fonctionne, les visiteurs ne se plaignent pas, tout semble normal. Jusqu’au jour où le référencement s’effondre, où l’hébergeur bloque le site, ou où Google applique une sanction. C’est précisément pour éviter ce scénario que la surveillance régulière reste indispensable.

Des cas concrets, parfois particulièrement vicieux

Sur le terrain, les attaques ne ressemblent pas toujours à ce que l’on imagine.

Il y a quelques jours, nous sommes intervenus sur un site déjà passé entre plusieurs mains, sans succès. À chaque tentative de nettoyage, le problème revenait. Inlassablement. L’audit a fini par révéler l’origine du problème : la base de données elle-même était compromise. Un trigger (action automatique au niveau de la base de données) y avait été ajouté, permettant de créer automatiquement un compte administrateur dès qu’un type de commentaire bien précis était publié sur le site. Aucun fichier suspect en apparence. Aucune extension clairement malveillante. Et pourtant, à chaque nettoyage, le pirate pouvait reprendre la main. Le genre de mécanisme discret, durable, et particulièrement difficile à détecter si l’on ne pense pas à regarder à cet endroit-là.

Dans d’autres cas, ce ne sont pas WordPress ni sa base de données qui sont directement en cause, mais le serveur. Il arrive que des tâches planifiées, des cron jobs, soient ajoutées à l’insu du propriétaire du site. Des scripts s’exécutent alors automatiquement, sans passer par WordPress, parfois même après une restauration complète. Là encore, la persistance est redoutable.

Les fichiers sont un autre terrain de jeu classique. Des images parfaitement banales – JPEG, PNG – peuvent contenir du code malveillant dissimulé. À l’œil nu, rien d’anormal. Côté serveur, en revanche, le fichier est interprété et exécuté. Même logique avec certaines extensions frauduleuses : elles portent des noms crédibles, reprennent les conventions de WordPress, imitent les classes et les fonctions attendues. Tout est fait pour se fondre dans le décor.

Et puis il y a les attaques à grande échelle, souvent découvertes trop tard. Un petit site vitrine, une dizaine ou une vingtaine de pages tout au plus, qui se retrouve du jour au lendemain avec plusieurs millions d’URL indexées par Google. Pages de spam, faux catalogues, promotions de doudounes, de casinos ou de médicaments. Le site fonctionne toujours. Le client ne voit rien. Mais le référencement, lui, est déjà irrémédiablement compromis.

Ces situations ont un point commun : elles ne relèvent pas d’un simple “piratage visible”. Elles exploitent la durée, la discrétion et la méconnaissance. C’est précisément pour cela que la sécurité ne peut pas se limiter à un nettoyage ponctuel ou à l’installation d’un outil. Elle suppose une analyse approfondie, une compréhension de l’environnement complet – WordPress, base de données, serveur – et une surveillance dans le temps.