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

Word­Press ali­mente aujourd’hui plus de 40% du web. Avec cette popu­la­ri­té on peut se poser une ques­tion : la sécu­ri­té Word­Press est-elle fiable ?

Aujourd’­hui je donne la parole à Thier­ry Pigot, expert en sécu­ri­té Word­Press.

Je lui ai posé 12 ques­tions. L’in­ter­view se ter­mine avec des cas concrets. 

Thier­ry Pigot tra­vaille avec Word­Press depuis 2005, d’a­bord comme déve­lop­peur, puis très vite sur les sujets de main­te­nance, de sup­port et de fia­bi­li­té des sites. Avec le temps, la sécu­ri­té est deve­nue un axe cen­tral de son acti­vi­té, non pas par spé­cia­li­sa­tion oppor­tu­niste, mais parce qu’elle s’im­po­sait sur le terrain.

WP Assis­tance est née de cette réa­li­té : pour Thier­ry, un site Word­Press n’est jamais “ter­mi­né”. Il vit, évo­lue, se met à jour, et doit être sur­veillé. La sécu­ri­té n’est donc pas un état, mais un tra­vail conti­nu, sou­vent invi­sible, tou­jours nécessaire.

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

Si l’on parle stric­te­ment de sécu­ri­té, cela fait envi­ron quinze ans.
Mais dans les faits, la fron­tière entre main­te­nance et sécu­ri­té est mince. Dès lors que l’on gère des mises à jour, des sau­ve­gardes, des inci­dents ou des res­tau­ra­tions après pro­blème, on touche déjà à des enjeux de protection.

Avec la géné­ra­li­sa­tion des attaques auto­ma­ti­sées, l’é­mer­gence de l’IA et un contexte géo­po­li­tique plus ten­du, la sécu­ri­té est deve­nue un sujet struc­tu­rant, et non plus un simple « plus » technique.

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

L’i­dée que Word­Press serait intrin­sè­que­ment peu sûr.
C’est une affir­ma­tion qui revient sou­vent, et qui repose sur­tout sur une confusion.

Le cœur de Word­Press est glo­ba­le­ment robuste. Il est audi­té, main­te­nu, cor­ri­gé rapi­de­ment lors­qu’une vul­né­ra­bi­li­té est iden­ti­fiée. Dans la très grande majo­ri­té des cas que nous trai­tons, le pro­blè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 pro­viennent prin­ci­pa­le­ment des exten­sions, puis des thèmes.
C’est logique : ce sont des briques de code ajou­tées, par­fois déve­lop­pées par de petites équipes, par­fois aban­don­nées, par­fois mal main­te­nues. Leur carac­tère open-source rend le code acces­sible, ce qui faci­lite l’a­na­lyse et la détec­tion de failles, aus­si bien par la com­mu­nau­té que par des attaquants.

Il faut aus­si men­tion­ner un point géné­ra­le­ment sous-esti­mé : les confi­gu­ra­tions ser­veur inadap­tées. Un site peut être par­fai­te­ment à jour côté Word­Press, mais res­ter vul­né­rable si l’en­vi­ron­ne­ment d’hé­ber­ge­ment laisse pas­ser cer­taines attaques ou expose inuti­le­ment des res­sources sensibles.

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

Parce que la sécu­ri­té dépend direc­te­ment de la qua­li­té du code et du sui­vi dans le temps.
Une exten­sion main­te­nue, docu­men­tée, mise à jour régu­liè­re­ment et issue d’une source iden­ti­fiée pré­sente beau­coup moins de risques qu’un com­po­sant récu­pé­ré sans réel contrôle.

Dans les cas de pira­tage que nous ana­ly­sons, il n’est pas rare de retrou­ver des exten­sions aban­don­nées depuis plu­sieurs années, ou des thèmes modi­fiés dont l’o­ri­gine est floue.

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

Oui, et c’est même assez fré­quent.
Cer­taines vul­né­ra­bi­li­tés n’ont aucun impact visible tant qu’elles ne sont pas exploi­tées. Le site fonc­tionne nor­ma­le­ment, sans mes­sage d’er­reur, sans com­por­te­ment sus­pect apparent.

Cela crée un faux sen­ti­ment de sécu­ri­té, alors que le pro­blème est bien présent.

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

C’est exact.
Il existe des méca­nismes où du code mal­veillant ou une porte déro­bée reste inac­tive jus­qu’à ce qu’une condi­tion pré­cise soit rem­plie : un type de requête, un para­mètre par­ti­cu­lier, par­fois même une date.

C’est l’une des rai­sons pour les­quelles cer­tains pira­tages semblent “tom­ber du ciel”, alors que l’in­fec­tion ini­tiale est par­fois ancienne.

Mises à jour automatiques ou gestion manuelle ?

Les deux ont leur place.
Les mises à jour auto­ma­tiques du cœur Word­Press et des cor­rec­tifs de sécu­ri­té per­mettent de réduire for­te­ment les délais d’ex­po­si­tion aux failles connues. C’est un point positif.

Pour les exten­sions plus sen­sibles ou cri­tiques pour l’ac­ti­vi­té du site, une ges­tion super­vi­sée reste pré­fé­rable. Elle per­met de tes­ter, de véri­fier les com­pa­ti­bi­li­tés et d’é­vi­ter des effets de bord.

Que sont les attaques par force brute ?

Il s’a­git de ten­ta­tives auto­ma­ti­sées visant à devi­ner des iden­ti­fiants de connexion en tes­tant un grand nombre de com­bi­nai­sons.
Ces attaques sont simples, mais effi­caces lorsque les mots de passe sont faibles ou lors­qu’au­cune limi­ta­tion n’est en place.

Les mesures de pro­tec­tion sont connues : limi­ta­tion des ten­ta­tives, mots de passe robustes, authen­ti­fi­ca­tion à deux fac­teurs, fil­trage côté serveur.

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

Oui, clai­re­ment.
Cer­taines défenses sont bien plus effi­caces lors­qu’elles sont mises en œuvre au niveau ser­veur : fil­trage des requêtes, pare-feu appli­ca­tif, limi­ta­tion des accès, pro­tec­tion contre cer­taines attaques automatisées.

Les exten­sions Word­Press ont leur uti­li­té, mais elles inter­viennent trop tard dans la chaîne si le ser­veur laisse pas­ser des flux malveillants.

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

Une approche cohé­rente, pas une accu­mu­la­tion d’ou­tils.
Un héber­ge­ment sérieux, des exten­sions choi­sies avec dis­cer­ne­ment, des mises à jour sui­vies, des sau­ve­gardes fiables et tes­tées, et une sur­veillance régulière.

La sécu­ri­té n’est pas un pro­duit que l’on ins­talle une fois. C’est une discipline.

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

1. Main­te­nir l’en­semble du site à jour.
2. Limi­ter stric­te­ment le nombre d’ex­ten­sions utilisées.
3. Mettre en place des sau­ve­gardes auto­ma­tiques, avec des tests de restauration.

Ces trois points couvrent déjà une grande par­tie des risques courants.

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

Ils peuvent être évi­dents : redi­rec­tions vers des sites tiers, mes­sages d’a­lerte des navi­ga­teurs, conte­nus modi­fiés ou comptes admi­nis­tra­teurs inconnus.

Ils peuvent aus­si être beau­coup plus dis­crets, et donc plus dan­ge­reux. Une aug­men­ta­tion sou­daine et inex­pli­quée du nombre de pages détec­tées dans la Search Console de Google, par exemple. On y découvre par­fois des cen­taines, voire des mil­liers d’URL qui n’ont jamais été créées volon­tai­re­ment : pages de spam, conte­nus para­sites, faux cata­logues produits.

Autre signal très par­lant : des liens injec­tés à des fins SEO, invi­sibles pour l’in­ter­naute, mais bien pré­sents dans le code ou des envois d’e-mails inha­bi­tuels depuis le site.

Mais la plu­part du temps, il n’y a aucun signe immé­dia­te­ment visible. Le site fonc­tionne, les visi­teurs ne se plaignent pas, tout semble nor­mal. Jus­qu’au jour où le réfé­ren­ce­ment s’ef­fondre, où l’hé­ber­geur bloque le site, ou où Google applique une sanc­tion. C’est pré­ci­sé­ment pour évi­ter ce scé­na­rio que la sur­veillance régu­lière reste indispensable.

Des cas concrets, parfois particulièrement vicieux

Sur le ter­rain, les attaques ne res­semblent pas tou­jours à ce que l’on imagine.

Il y a quelques jours, nous sommes inter­ve­nus sur un site déjà pas­sé entre plu­sieurs mains, sans suc­cès. À chaque ten­ta­tive de net­toyage, le pro­blème reve­nait. Inlas­sa­ble­ment. L’au­dit a fini par révé­ler l’o­ri­gine du pro­blème : la base de don­nées elle-même était com­pro­mise. Un trig­ger (action auto­ma­tique au niveau de la base de don­nées) y avait été ajou­té, per­met­tant de créer auto­ma­ti­que­ment un compte admi­nis­tra­teur dès qu’un type de com­men­taire bien pré­cis était publié sur le site. Aucun fichier sus­pect en appa­rence. Aucune exten­sion clai­re­ment mal­veillante. Et pour­tant, à chaque net­toyage, le pirate pou­vait reprendre la main. Le genre de méca­nisme dis­cret, durable, et par­ti­cu­liè­re­ment dif­fi­cile à détec­ter si l’on ne pense pas à regar­der à cet endroit-là.

Dans d’autres cas, ce ne sont pas Word­Press ni sa base de don­nées qui sont direc­te­ment en cause, mais le ser­veur. Il arrive que des tâches pla­ni­fiées, des cron jobs, soient ajou­tées à l’in­su du pro­prié­taire du site. Des scripts s’exé­cutent alors auto­ma­ti­que­ment, sans pas­ser par Word­Press, par­fois même après une res­tau­ra­tion com­plète. Là encore, la per­sis­tance est redoutable.

Les fichiers sont un autre ter­rain de jeu clas­sique. Des images par­fai­te­ment banales – JPEG, PNG – peuvent conte­nir du code mal­veillant dis­si­mu­lé. À l’œil nu, rien d’a­nor­mal. Côté ser­veur, en revanche, le fichier est inter­pré­té et exé­cu­té. Même logique avec cer­taines exten­sions frau­du­leuses : elles portent des noms cré­dibles, reprennent les conven­tions de Word­Press, imitent les classes et les fonc­tions atten­dues. Tout est fait pour se fondre dans le décor.

Et puis il y a les attaques à grande échelle, sou­vent décou­vertes trop tard. Un petit site vitrine, une dizaine ou une ving­taine de pages tout au plus, qui se retrouve du jour au len­de­main avec plu­sieurs mil­lions d’URL indexées par Google. Pages de spam, faux cata­logues, pro­mo­tions de dou­dounes, de casi­nos ou de médi­ca­ments. Le site fonc­tionne tou­jours. Le client ne voit rien. Mais le réfé­ren­ce­ment, lui, est déjà irré­mé­dia­ble­ment compromis.

Ces situa­tions ont un point com­mun : elles ne relèvent pas d’un simple “pira­tage visible”. Elles exploitent la durée, la dis­cré­tion et la mécon­nais­sance. C’est pré­ci­sé­ment pour cela que la sécu­ri­té ne peut pas se limi­ter à un net­toyage ponc­tuel ou à l’ins­tal­la­tion d’un outil. Elle sup­pose une ana­lyse appro­fon­die, une com­pré­hen­sion de l’en­vi­ron­ne­ment com­plet – Word­Press, base de don­nées, ser­veur – et une sur­veillance dans le temps.