Une bonne gouvernance est la base de la sécurité WordPress

Les risques liés à la sécurité de WordPress trouvent principalement leur origine dans des défaillances de gouvernance

WordPress occupe une place parmi les plus importantes sur Internet. Une telle envergure attire naturellement les pirates. Mais ce n’est pas l’envergure qui constitue le véritable problème. C’est la gouvernance.

De nombreuses organisations considèrent WordPress comme une simple plateforme marketing et le gèrent donc différemment des autres systèmes de production. Cette décision engendre des risques inutiles. Le site web est certes destiné au grand public, mais il reste étroitement lié aux activités de l’entreprise, à son infrastructure, à la confiance des clients et à la réputation de la marque. Lorsqu’un pirate parvient à y accéder, les répercussions se limitent rarement au site web.

Le schéma habituel est étonnamment constant. L’équipe d’ingénierie gère l’infrastructure. L’équipe marketing gère le contenu. Une agence externe développe de nouvelles fonctionnalités. L’équipe de sécurité élabore les politiques. Personne n’assume l’ensemble du cycle de vie de la sécurité. À mesure que les responsabilités se fragmentent, des tâches importantes telles que la gestion des correctifs, les contrôles d’accès, la maintenance de l’infrastructure et la gouvernance des plugins perdent progressivement de leur priorité. Les pirates tirent bien plus souvent parti de ces lacunes opérationnelles que des failles inhérentes à WordPress lui-même.

La gouvernance détermine également la rapidité avec laquelle une organisation réagit face à un changement. Une vulnérabilité récemment révélée ne constitue qu’une partie du problème. Quelqu’un doit la surveiller, déterminer si elle affecte l’activité, valider le correctif, approuver son déploiement et s’assurer que la mise à jour est bien appliquée en production. Si ces responsabilités ne sont pas clairement définies, même les vulnérabilités connues restent exposées.

Cela revêt une importance particulière, car la compromission d’un environnement WordPress se traduit rarement par un simple incident informatique. Les équipes de sécurité sont alors mobilisées. Les ressources techniques sont détournées de leurs missions stratégiques. Les dirigeants doivent gérer la communication avec les parties prenantes. Selon l’organisation, les équipes chargées de la conformité, les auditeurs, les autorités de régulation et les clients peuvent également être amenés à intervenir. Ce qui n’était au départ qu’un problème lié au site web devient rapidement un enjeu pour l’entreprise.

Pour les dirigeants, la question est simple : WordPress est-il géré avec la même rigueur opérationnelle que n’importe quel autre système de production ? Si la réponse est non, cela signifie que l’entreprise accepte un risque par nature.

La bonne nouvelle, c’est que la gouvernance est l’un des problèmes de sécurité les plus faciles à résoudre. Une responsabilité clairement établie, des processus bien définis, des normes techniques cohérentes et la responsabilisation des dirigeants permettent d’éliminer bon nombre des failles que les pirates exploitent systématiquement. La technologie a son importance, mais la rigueur opérationnelle est généralement plus déterminante.

Les exceptions opérationnelles font de WordPress une plateforme d’un coût et d’un risque disproportionnés

WordPress est extrêmement flexible. Cette flexibilité est précieuse, car elle permet aux équipes de mettre en place rapidement de nouvelles fonctionnalités. Cependant, une flexibilité sans discipline engendre une complexité opérationnelle qui ne cesse de s’accroître avec le temps.

La plupart des organisations ne se retrouvent pas du jour au lendemain à gérer un environnement WordPress à haut risque. Le risque s’accroît progressivement. De nouveaux plugins sont ajoutés pour soutenir des campagnes. Du code personnalisé est intégré pour répondre aux besoins métier. Les agences livrent des projets dans des délais serrés. Différentes équipes se voient attribuer des droits d’administrateur. Les processus de mise en production deviennent incohérents. Aucune de ces décisions ne semble significative en soi, mais, cumulées, elles créent un environnement dont la sécurisation et la maintenance deviennent de plus en plus difficiles.

Au final, l’organisation consacre davantage de temps à la gestion des risques opérationnels qu’à la création de valeur pour l’entreprise.

L’un des signes les plus évidents est la prolifération incontrôlée des plugins. Chaque plugin introduit un nouveau fournisseur de logiciels, un nouveau cycle de mise à jour, une nouvelle vulnérabilité potentielle et une nouvelle dépendance opérationnelle. Une personnalisation poussée pose un défi similaire, car les mises à jour de routine deviennent plus difficiles à effectuer. Les équipes retardent l’application des correctifs par crainte que les nouvelles versions ne compromettent les fonctionnalités personnalisées, ce qui prolonge l’exposition de l’organisation aux vulnérabilités connues.

La responsabilité est un autre facteur majeur. Les prestataires externes fournissent souvent un excellent travail, mais ils ne doivent pas devenir les responsables à long terme de la sécurité opérationnelle. Les équipes marketing se concentrent naturellement sur les résultats commerciaux, tels que les campagnes, l’engagement client et la rapidité de publication. L’ingénierie se concentre sur la fiabilité. La sécurité se concentre sur les risques. En l’absence d’une gouvernance claire qui relie ces priorités, des lacunes opérationnelles apparaissent inévitablement.

Les exigences de conformité viennent encore compliquer la situation. Les organisations opérant dans des secteurs réglementés doivent faire la preuve de contrôles de sécurité cohérents, de processus documentés et d’une responsabilité clairement définie. Un environnement caractérisé par un manque de clarté quant à la responsabilité, des mises à jour irrégulières et des composants tiers non gérés devient de plus en plus difficile à défendre lors des audits.

Les dirigeants devraient régulièrement évaluer si WordPress continue de justifier son coût d’exploitation. Si la plateforme nécessite une attention technique constante simplement pour garantir sa sécurité, l’entreprise devrait déterminer si cet investissement correspond toujours à ses priorités stratégiques.

Dans certaines situations, renforcer la gouvernance est la bonne décision. Dans d’autres, simplifier l’architecture, adopter une approche « headless » ou migrer vers une autre plateforme peut permettre de réduire le risque opérationnel à long terme. La bonne réponse dépend des objectifs métier plutôt que des préférences technologiques.

Ce qu’il faut retenir, c’est que la complexité ne doit jamais devenir le modèle de fonctionnement par défaut. Chaque dérogation aux pratiques d’ingénierie standard engendre des coûts opérationnels supplémentaires. Chaque dérogation accroît également les risques de sécurité auxquels l’organisation est exposée. Les organisations les plus résilientes s’efforcent en permanence de réduire la complexité inutile, au lieu de la laisser s’accumuler.

Les plugins et les thèmes constituent le principal facteur de risque en matière de sécurité et doivent faire l’objet d’une gestion rigoureuse

La plupart des discussions sur la sécurité de WordPress commencent par le cœur de la plateforme. C’est compréhensible, mais ce n’est pas là que réside l’essentiel du risque. Le véritable problème réside dans l’écosystème des plugins et des thèmes.

Chaque plugin introduit du code externe dans votre environnement. Cela signifie que chaque installation relève d’une décision stratégique. La qualité de ces composants varie considérablement. Certains sont gérés par des entreprises bien établies, dotées de pratiques de sécurité éprouvées. D’autres sont gérés par des développeurs indépendants disposant de ressources limitées. Les organisations doivent prendre conscience que ces différences ont une incidence directe sur le risque opérationnel.

Les données de Patchstack relatives aux vulnérabilités en 2024 illustrent clairement ce point. Elles ont permis d’identifier 7 966 vulnérabilités WordPress, dont 96 % concernaient des plugins et 4 % des thèmes. La conclusion est simple : le principal risque de sécurité ne réside pas dans le logiciel WordPress lui-même, mais dans les logiciels tiers que les organisations choisissent d’installer.

C’est pourquoi la gouvernance des plugins doit être considérée comme un processus de gestion formel plutôt que comme une simple validation informelle. Avant d’ajouter un plugin, la direction doit demander aux équipes de répondre à plusieurs questions concrètes. Le plugin fait-il l’objet d’une maintenance active ? Le développeur a-t-il fait ses preuves en matière de sécurité ? La fonctionnalité est-elle essentielle à l’activité ou simplement pratique ? Nécessite-t-elle des droits d’accès élevés ? Qui sera responsable du plugin tout au long de son cycle de vie ?

Ces questions sont importantes car les logiciels évoluent constamment. Les plugins font l’objet de mises à jour, des failles de sécurité sont découvertes, les développeurs abandonnent certains projets et les besoins métier changent. En l’absence d’une prise en charge continue, les composants restent en production bien après avoir cessé d’apporter une valeur ajoutée significative.

Les équipes marketing ont souvent besoin de flexibilité pour lancer rapidement des campagnes, mais l’installation sans restriction de plugins engendre des risques inutiles. La gouvernance doit favoriser l’innovation sans pour autant compromettre la discipline opérationnelle. Une revue technique, des critères d’approbation documentés et une attribution claire des responsabilités permettent aux organisations d’agir rapidement tout en conservant le contrôle sur les environnements de production.

Les dirigeants doivent également accorder une attention particulière à la santé à long terme de leur parc de plugins. Une organisation disposant de dizaines de plugins rarement utilisés présente une complexité opérationnelle nettement plus élevée qu’une autre dont l’ensemble des dépendances est soigneusement géré et régulièrement revu. La suppression des logiciels superflus constitue souvent l’un des moyens les plus simples de réduire la surface d’attaque.

Selon le rapport « State of WordPress Security in 2025 » publié par Patchstack, plus de la moitié des vulnérabilités signalées aux développeurs de plugins au cours de l’année 2024 n’avaient toujours pas fait l’objet d’un correctif au moment de leur divulgation publique. De plus, 24 % d’entre elles ne disposaient d’aucun correctif disponible au moment de la divulgation. Cela signifie que les organisations ne peuvent pas partir du principe que les fournisseurs résoudront rapidement ces problèmes. Une gouvernance interne reste donc essentielle.

Les plugins et thèmes piratés, ou « nullés », méritent une attention particulière. Ils ne doivent en aucun cas être considérés comme un raccourci en matière de licence. Ils constituent un risque pour la sécurité de la chaîne d’approvisionnement, car ils peuvent contenir du code malveillant ou des modifications non autorisées avant même d’être mis en production. La réponse appropriée est simple : interdire leur utilisation par le biais d’une politique et les détecter activement dans l’ensemble de l’environnement.

Une bonne gouvernance des plugins consiste en définitive à réduire les dépendances superflues, à attribuer clairement les responsabilités et à s’assurer que chaque composant tiers continue de justifier les risques opérationnels et de sécurité qu’il engendre.

La mise en place rapide de correctifs est essentielle et nécessite une répartition claire des responsabilités ainsi que des processus rationalisés

La rapidité des attaques actuelles a profondément modifié le rôle de la gestion des correctifs. Les entreprises ne peuvent plus se permettre de considérer les mises à jour comme une opération de maintenance courante pouvant attendre la prochaine fenêtre de déploiement appropriée.

En avril 2025, Patchstack a recensé une vulnérabilité critique du plugin SureTriggers qui a été exploitée dans les quatre heures suivant son apparition dans sa base de données des vulnérabilités. Ce délai ne laisse que très peu de place à l’incertitude ou à la lenteur dans la prise de décision.

Il est important de noter que la publication d’un correctif de sécurité ne réduit pas automatiquement le risque. Le risque ne diminue que lorsque les organisations identifient les systèmes concernés, évaluent l’impact, valident la mise à jour et la déploient avec succès en environnement de production. Tout retard prolonge la période pendant laquelle les attaquants peuvent exploiter les failles connues.

De nombreuses organisations rencontrent des difficultés car les responsabilités sont réparties entre plusieurs équipes. Un groupe assure la surveillance des vulnérabilités. Un autre gère l’infrastructure. Une autre équipe encore est en charge de l’application. Des prestataires externes peuvent prendre en charge le déploiement. En l’absence de responsabilité clairement définie, les décisions critiques sont prises plus lentement, précisément au moment où la rapidité est primordiale.

Dans ce contexte, la maturité opérationnelle devient un avantage concurrentiel. Les organisations qui disposent d’environnements de test fiables peuvent tester rapidement les mises à jour sans exposer l’environnement de production à des risques inutiles. La surveillance continue des logiciels installés, comparée à des bases de données de vulnérabilités fiables, permet aux équipes d’identifier immédiatement les systèmes concernés, sans avoir à recourir à des vérifications manuelles.

Trois mesures pratiques permettent d’améliorer systématiquement les résultats : la vérification des versions installées par rapport à des sources de vulnérabilités connues telles que WPScan, la validation des mises à jour importantes dans les environnements de préproduction, et la désignation d’un responsable chargé de prendre les décisions relatives aux correctifs et de les faire remonter à la hiérarchie. Il s’agit là autant de décisions de gestion que de décisions techniques.

La direction doit également définir clairement les attentes avant qu’un incident ne se produise. Les équipes doivent savoir qui est habilité à approuver les correctifs d’urgence, dans quels délais les vulnérabilités critiques doivent être évaluées, et quelle est la procédure d’escalade à suivre si le déploiement ne peut pas avoir lieu immédiatement. Ces décisions sont difficiles à prendre en pleine crise de sécurité. Elles sont bien plus faciles à prendre lorsqu’elles ont été documentées à l’avance.

Le défi ne se limite pas aux mises à jour logicielles. Les entreprises retardent souvent l’application des correctifs par crainte de perturber leurs services de production. Cette préoccupation est compréhensible, mais retarder les mises à jour peut entraîner un risque encore plus important pour l’entreprise si des vulnérabilités connues du grand public restent exposées pendant de longues périodes. Les entreprises matures trouvent un équilibre entre la stabilité opérationnelle et la sécurité, plutôt que de les considérer comme des priorités contradictoires.

Le rapport annuel de sécurité 2024 de Wordfence a révélé que 35 % des vulnérabilités WordPress rendues publiques en 2024 n’avaient toujours pas fait l’objet d’un correctif au moment de la publication du rapport, début 2025. Une vulnérabilité pour laquelle un correctif est déjà disponible peut continuer de représenter un risque réel si les organisations ne mettent pas en œuvre le processus de mise à jour.

Pour les dirigeants, la gestion des correctifs doit être considérée comme un élément de gouvernance. Une responsabilité clairement établie, des délais de réponse bien définis et des processus opérationnels rigoureux déterminent si les vulnérabilités restent des risques théoriques ou se transforment en incidents de sécurité coûteux.

Une gestion efficace des accès privilégiés ne se limite pas à la sécurisation des mots de passe, mais vise également à garantir une gouvernance rigoureuse des droits d’accès

La gestion des accès est souvent abordée sous l’angle des mots de passe. Ce n’est là qu’une partie du problème. La question plus large est de savoir qui dispose d’un accès, pourquoi il en dispose et si cet accès est toujours nécessaire.

Les environnements WordPress voient naturellement leur nombre d’utilisateurs augmenter au fil du temps. Les collaborateurs changent de poste. Les agences mènent à bien leurs projets. Les prestataires quittent l’entreprise. De nouveaux plugins introduisent leurs propres modèles d’autorisation. Si les organisations ne passent pas régulièrement ces changements en revue, les privilèges d’administrateur continuent de s’étendre sans justification métier claire.

Cela crée une vulnérabilité inutile. Un attaquant n’a pas besoin de compromettre tous les comptes. Un seul compte privilégié peut suffire pour modifier du contenu, installer des plugins malveillants, créer des utilisateurs administrateurs supplémentaires ou s’implanter durablement au sein de l’environnement. Plus l’accès administratif est étendu, plus l’impact potentiel d’une compromission réussie est important.

Les méthodes d’attaque courantes, telles que l’hameçonnage, la réutilisation d’identifiants, le vol de session et la compromission des terminaux, deviennent nettement plus destructrices lorsque des privilèges excessifs sont déjà en place. La compromission initiale peut être relativement simple, mais une gouvernance défaillante permet à l’attaquant de s’infiltrer bien plus profondément dans le système.

Selon les données de Patchstack pour 2024, les failles liées à un contrôle d’accès défaillant représentaient 14,19 % des vulnérabilités WordPress rendues publiques. Cela montre clairement que la gouvernance des accès n’est pas simplement une bonne pratique opérationnelle ; il s’agit d’un problème de sécurité récurrent au sein de l’écosystème WordPress.

L’authentification multifactorielle (MFA), généralement mise en œuvre sous la forme d’une authentification à deux facteurs, doit être considérée comme une mesure de sécurité de base. Elle réduit considérablement le risque que le vol de mots de passe suffise à lui seul à permettre un accès non autorisé. Cependant, la MFA ne constitue pas une solution complète. Si un trop grand nombre d’utilisateurs conserve des privilèges d’administrateur, si des comptes sont partagés ou si d’anciens contributeurs continuent d’avoir accès au système, le problème de gouvernance sous-jacent persiste.

Les dirigeants doivent veiller à ce que leurs organisations mettent en œuvre un processus structuré de gestion des identités et des accès pour WordPress, conforme aux pratiques générales de sécurité de l’entreprise. Cela implique notamment d’appliquer le principe du « privilège minimal », de procéder à des vérifications régulières des comptes administrateurs, de supprimer sans délai les droits d’accès inutiles lorsque des collaborateurs ou des prestataires quittent l’entreprise, d’interdire le partage des identifiants d’administrateur, d’appliquer des politiques de mots de passe forts et de limiter le nombre de tentatives de connexion successives.

Les fonctionnalités héritées méritent également l’attention de la direction. Le fichier xmlrpc.php, et en particulier sa fonctionnalité « system.multicall », permet aux attaquants de regrouper des milliers de tentatives d’authentification en une seule requête. Bien que le protocole XML-RPC reste nécessaire pour certaines intégrations, de nombreuses organisations n’en ont plus besoin. Des examens réguliers doivent permettre de déterminer si les points de terminaison hérités continuent de répondre à un besoin métier légitime. Si ce n’est pas le cas, ils doivent être désactivés ou faire l’objet de restrictions strictes.

La gouvernance des accès doit être considérée comme une discipline opérationnelle permanente plutôt que comme un projet de sécurité ponctuel. Chaque nouvel employé, prestataire, fournisseur ou initiative commerciale entraîne des modifications potentielles des droits d’accès. Un examen continu permet de s’assurer que ces modifications restent en adéquation avec les besoins de l’entreprise tout en limitant les risques inutiles.

La gouvernance de l’infrastructure est tout aussi essentielle à la sécurité de WordPress, même lorsque la plateforme semble bien entretenue

Les entreprises se concentrent souvent sur WordPress lui-même, tout en accordant moins d’attention à l’environnement qui le soutient. Cela engendre des risques inutiles, car la sécurité des applications dépend fortement de celle de l’infrastructure.

Même une installation WordPress entièrement mise à jour peut rester vulnérable si elle fonctionne sur un logiciel non pris en charge, une infrastructure d’hébergement mal gérée, avec des droits d’accès aux fichiers non sécurisés ou des interfaces d’administration mal configurées. Les pirates recherchent des failles dans l’ensemble de l’environnement.

Plusieurs mesures de contrôle fondamentales devraient être considérées comme obligatoires. Il s’agit notamment de maintenir les versions d’exécution prises en charge, d’appliquer des autorisations sécurisées pour les fichiers et les configurations, de restreindre l’accès aux répertoires sensibles et aux éléments du référentiel, de limiter les points de terminaison hérités inutiles, et de séparer clairement les responsabilités liées à l’infrastructure de la gestion des applications. Ces mesures réduisent les possibilités pour les attaquants d’exploiter des failles de configuration qui ne sont pas liées au code de WordPress lui-même.

La gestion du cycle de vie des applications en environnement d’exécution est un domaine qui mérite une surveillance constante de la part de la direction. Les éditeurs de logiciels finissent par cesser de fournir des mises à jour de sécurité pour les anciennes versions de leurs produits. Une fois ce support terminé, il incombe aux organisations de gérer les risques supplémentaires en mettant en place des contrôles compensatoires ou en accélérant les mises à niveau.

Le cycle de vie officiel du support de PHP illustre bien ce défi. PHP 7.4 a atteint sa fin de vie en novembre 2022, PHP 8.0 en novembre 2023, et PHP 8.1 atteindra sa fin de vie en décembre 2025. Il convient également de noter que les données d’utilisation de WordPress continuent de montrer qu’un pourcentage significatif de sites web fonctionne avec des versions de PHP qui ne sont plus prises en charge. Cela accroît le risque opérationnel et complique les audits de sécurité, la conformité réglementaire et les futurs efforts de mise à niveau.

L’hébergement WordPress géré permet d’améliorer le niveau de sécurité de base en prenant en charge de nombreuses tâches liées à l’infrastructure, notamment la maintenance courante, l’application des correctifs système et les bonnes pratiques opérationnelles. Ces services réduisent souvent les risques courants liés à l’infrastructure grâce à des environnements standardisés et à une maintenance continue.

Toutefois, l’hébergement géré ne doit pas être considéré comme une stratégie de sécurité à part entière. Il ne permet pas de contrôler les plugins installés par une organisation, de déterminer qui bénéficie d’un accès administrateur, ni de mettre en place des processus d’approbation internes. Ces responsabilités incombent toujours à l’organisation.

Un autre point important concerne la fragmentation organisationnelle. Le service marketing peut être responsable du contenu. Le service d’ingénierie peut gérer l’hébergement. Le service de sécurité peut définir la politique de sécurité. Des agences externes peuvent mettre en œuvre de nouvelles fonctionnalités. Chaque groupe accomplit un travail précieux, mais à moins que quelqu’un ne soit responsable de l’ensemble du modèle de sécurité, des lacunes apparaissent naturellement entre ces différentes responsabilités.

Pour les dirigeants, la gouvernance de l’infrastructure relève en fin de compte davantage d’une question de leadership que d’une question purement technique. Une responsabilité clairement définie, des pratiques opérationnelles normalisées et la gestion du cycle de vie permettent de réduire les risques opérationnels à long terme tout en améliorant la résilience, la préparation aux audits et la continuité des activités. Les organisations qui considèrent la gouvernance de l’infrastructure comme une fonction métier continue sont généralement mieux à même de faire face à l’évolution des menaces de sécurité sans perturber leurs activités.

Les mesures de sécurité doivent être adaptées aux vecteurs d’attaque courants afin de limiter efficacement les menaces pesant sur WordPress

Un programme de sécurité n’est efficace que s’il prend en compte les attaques qui se produisent réellement. Trop d’organisations investissent dans des mesures de contrôle qui semblent exhaustives sur le papier, mais qui ne parviennent pas à réduire les risques auxquels elles sont le plus souvent confrontées en environnement de production.

Les responsables techniques n’ont pas besoin de comprendre tous les détails techniques qui se cachent derrière chaque vulnérabilité de WordPress. Ils doivent toutefois avoir l’assurance que leurs mesures de sécurité s’attaquent directement aux méthodes les plus couramment utilisées par les pirates pour compromettre les sites web.

Les attaques de type « cross-site scripting » (XSS) restent l’un des problèmes les plus courants. Ces vulnérabilités permettent aux attaquants d’injecter du code malveillant via les saisies des utilisateurs, les workflows administratifs ou les paramètres d’URL. L’injection SQL cible les failles dans les requêtes de base de données, tandis que la falsification de requêtes intersites (CSRF) incite des utilisateurs de confiance à effectuer des actions non souhaitées. Les pages de connexion publiques continuent de faire l’objet d’attaques par force brute et de campagnes de « credential stuffing », tandis que les plugins et thèmes tiers constituent un risque permanent lié à la chaîne d’approvisionnement.

Chacune de ces voies d’attaque nécessite une stratégie de contrôle différente. Les pratiques de codage sécurisé permettent de réduire les failles logicielles avant le déploiement. L’application rapide des correctifs élimine les vulnérabilités connues. La validation des requêtes contribue à prévenir les actions non autorisées. La limitation du débit et l’authentification multifactorielle réduisent l’efficacité des attaques de connexion automatisées. La gouvernance des fournisseurs garantit que les organisations comprennent le niveau de sécurité des logiciels tiers sur lesquels elles s’appuient. La surveillance de l’intégrité et les analyses de sécurité régulières améliorent les chances de détecter les modifications non autorisées avant qu’elles ne se transforment en incidents majeurs.

Les organisations doivent éviter de s’appuyer sur un seul dispositif de sécurité. L’application de correctifs est essentielle, mais elle ne peut pas prévenir tous les types d’attaques. Si un éditeur de logiciels de confiance est compromis avant la diffusion des mises à jour, les organisations risquent de recevoir des logiciels malveillants par des canaux légitimes. La sécurité nécessite donc la mise en place de plusieurs dispositifs complémentaires, plutôt que de reposer sur une seule technologie ou un seul processus.

Les données de Patchstack pour 2024 démontrent pourquoi ces priorités sont importantes. Le rapport a révélé que 43 % des vulnérabilités de WordPress ne nécessitaient aucune authentification, ce qui signifie que les attaquants pouvaient les exploiter sans avoir à compromettre au préalable les comptes des utilisateurs. Près de la moitié de toutes les vulnérabilités signalées concernaient des failles de type « cross-site scripting », les injections SQL et les défaillances du contrôle d’accès constituant les catégories suivantes les plus courantes.

L’ampleur des attaques en cours est tout aussi considérable. Wordfence a indiqué avoir bloqué plus de 9 milliards de tentatives d’exploitation de failles de type « cross-site scripting » au cours de l’année 2024. Ces chiffres montrent que les attaquants ciblent systématiquement des failles bien connues plutôt que de se contenter de recourir à des techniques hautement sophistiquées.

Des capacités de restauration robustes sont essentielles, mais souvent insuffisamment développées dans les environnements WordPress

Il est important de prévenir les attaques, mais aucun programme de sécurité ne peut garantir que tous les incidents seront évités. La véritable mesure de la résilience réside dans l’efficacité avec laquelle une organisation détecte une intrusion, la maîtrise et se remet de celle-ci.

La reprise après sinistre fait l’objet de bien moins d’attention que la prévention, alors qu’elle a un impact considérable sur les perturbations opérationnelles, les pertes financières et l’atteinte à la réputation. De nombreuses organisations partent du principe qu’il suffit de disposer de sauvegardes. En réalité, une reprise réussie nécessite un ensemble de capacités bien plus large.

L’une des principales priorités réside dans la mise en place d’une surveillance efficace. Les environnements WordPress génèrent des signaux de sécurité que les plateformes de surveillance informatique classiques peuvent négliger. Il s’agit notamment de la création inattendue de comptes administrateur, de modifications non autorisées apportées aux fichiers du cœur du système, de tâches planifiées suspectes via WP-Cron et de l’apparition de nouveaux fichiers PHP dans les répertoires de téléchargement. La détection précoce de ces indicateurs peut réduire considérablement la durée pendant laquelle les attaquants restent indétectables.

En l’absence de surveillance continue, les organisations ne découvrent souvent une intrusion qu’après que des clients ont signalé un comportement suspect, que les moteurs de recherche ont signalé le site web ou que des chercheurs externes ont alerté l’entreprise. À ce stade, les attaquants ont peut-être déjà établi une présence persistante et causé des dommages plus importants.

Les pare-feu d’applications Web (WAF) permettent de bloquer les tentatives d’exploitation courantes et le trafic malveillant avant qu’ils n’atteignent l’application. Cependant, l’emplacement de déploiement du pare-feu a son importance. Les WAF en périphérie filtrent le trafic avant que les requêtes n’atteignent l’environnement d’hébergement et offrent généralement une protection plus étendue, notamment la protection contre les attaques par déni de service distribué (DDoS). Les WAF sous forme de plug-ins peuvent tout de même apporter une valeur ajoutée, mais comme ils fonctionnent au sein même de l’application qu’ils sont censés protéger, ils doivent être considérés comme un maillon d’une stratégie de sécurité plus large plutôt que comme le principal moyen de défense.

La planification de la reprise va bien au-delà de la simple restauration des données à partir des sauvegardes. Les organisations doivent s’assurer que les identifiants d’administrateur n’ont pas été compromis, supprimer toute porte dérobée présente dans les plugins, les thèmes ou les répertoires de téléchargement, éliminer les tâches planifiées malveillantes susceptibles de réinfecter l’environnement, et vérifier que la vulnérabilité d’origine a bien été corrigée avant de rétablir l’accès public. Dans le cas contraire, les attaquants pourraient retrouver l’accès presque immédiatement après la reprise.

Une sauvegarde non testée ne doit pas être considérée comme un dispositif de sécurité fiable. Les plans de reprise doivent inclure des sauvegardes automatisées, un stockage hors site, un historique des versions, des procédures de restauration documentées et des tests réguliers réalisés dans des conditions réalistes. Ces tests permettent de vérifier que les données peuvent être restaurées et que l’organisation est en mesure de reprendre ses activités rapidement et en toute sécurité.

Pour les dirigeants, la capacité de reprise après sinistre doit être considérée comme une compétence métier essentielle. Les clients, les partenaires, les autorités de régulation et les actionnaires sont tous concernés par la manière dont une organisation réagit à la suite d’un incident. Les organisations qui testent régulièrement leurs processus de reprise, surveillent en permanence les menaces et intègrent la détection à la planification des interventions sont généralement mieux à même de réduire au minimum les temps d’arrêt, de préserver la confiance des clients et de rétablir leurs activités normales en toute sérénité.

Les responsables techniques doivent définir clairement les responsabilités en matière de gestion de la sécurité de WordPress

La technologie à elle seule ne suffira pas à garantir la sécurité de WordPress. C’est le leadership qui détermine si la sécurité devient une capacité opérationnelle cohérente ou un ensemble d’activités disparates. La responsabilisation est le fondement d’un programme de sécurité efficace.

De nombreuses organisations répartissent les responsabilités entre plusieurs équipes. Le service marketing gère les contenus. L’équipe d’ingénierie assure la maintenance de l’infrastructure d’hébergement. Le service de sécurité élabore les politiques. Des agences externes développent de nouvelles fonctionnalités. Chaque équipe a un rôle légitime à jouer, mais lorsque personne n’assume la responsabilité de l’ensemble du cycle de vie des risques, des responsabilités importantes se retrouvent prises en sandwich entre les différentes structures organisationnelles.

Ce manque de responsabilisation se manifeste souvent de manière prévisible. Des plugins restent installés bien après qu’ils ne sont plus nécessaires. Des mises à jour critiques attendent d’être approuvées car les compétences décisionnelles ne sont pas clairement définies. Les comptes administrateurs s’accumulent sans faire l’objet d’un contrôle. Des plans de reprise existent sur le papier, mais n’ont jamais été testés. En règle générale, aucun de ces problèmes ne résulte d’un manque de technologie. Ils découlent d’un manque de clarté quant à la responsabilité.

Il existe cinq responsabilités de direction qui doivent être officiellement attribuées et faire l’objet d’un suivi continu.

Le premier point concerne la gouvernance des plugins. Chaque plugin doit faire l’objet d’un processus de validation défini, d’un responsable opérationnel désigné et d’évaluations régulières visant à déterminer s’il continue d’apporter une valeur suffisante au regard des risques opérationnels et de sécurité qu’il engendre. La suppression des logiciels superflus doit être considérée comme une activité de gouvernance continue plutôt que comme une opération de nettoyage ponctuelle.

La deuxième responsabilité concerne la gestion des interventions liées aux correctifs. Les organisations doivent définir des objectifs de délai de réponse pour les vulnérabilités critiques, mettre en place des procédures d’escalade, documenter les exigences en matière de tests et identifier clairement les personnes habilitées à approuver les déploiements d’urgence. Ces décisions doivent être prises avant que des incidents ne surviennent, afin de permettre aux équipes de réagir rapidement lorsque des vulnérabilités sont révélées.

La troisième responsabilité consiste à distinguer la gouvernance de la plateforme de celle des applications. La gestion de l’infrastructure, la planification du cycle de vie de l’exécution, les protections réseau et la sécurité de l’hébergement requièrent des compétences différentes de celles nécessaires au développement d’applications et à la gestion de contenu. L’attribution d’une responsabilité explicite à chaque domaine réduit les ambiguïtés opérationnelles tout en renforçant la responsabilisation au sein de l’organisation technologique.

La quatrième responsabilité concerne la gouvernance des accès privilégiés. Les accès administratifs doivent être réservés aux utilisateurs ayant un besoin métier légitime et faire l’objet d’un réexamen selon une fréquence définie. Tout changement concernant les fonctions des salariés, les missions des prestataires et les relations avec les fournisseurs doit déclencher automatiquement un réexamen des accès. Cela permet de réduire les risques inutiles tout en améliorant la préparation aux audits.

La cinquième responsabilité concerne la préparation à la reprise. Les sauvegardes ne suffisent pas à elles seules à garantir la résilience. Les organisations doivent tester régulièrement leurs procédures de restauration, vérifier que les environnements restaurés sont sécurisés et définir des objectifs de reprise mesurables, conformes aux exigences en matière de continuité d’activité. La reprise doit être gérée comme une capacité opérationnelle placée sous la supervision de la direction, plutôt que comme un processus d’urgence activé uniquement à la suite d’un incident de sécurité.

Les organisations doivent opter pour une stratégie claire. Elles peuvent gérer WordPress comme un système de production en lui appliquant les mêmes normes opérationnelles que celles en vigueur pour les autres plateformes technologiques critiques, ou bien le classer délibérément comme une exception gérée, avec des limites clairement définies et les risques associés. Ces deux approches peuvent être valables en fonction des objectifs de l’entreprise.

Ce qui engendre une vulnérabilité inutile, c’est de laisser WordPress se situer quelque part entre ces deux modèles. Une gouvernance incohérente entraîne une sécurité incohérente. Au fil du temps, les exceptions s’accumulent, les responsabilités deviennent moins claires et le risque opérationnel augmente.

Pour les dirigeants, WordPress ne doit pas être considéré comme une simple plateforme de gestion de contenu parmi d’autres. Il s’agit d’un actif de l’entreprise qui favorise l’engagement client, la réputation de la marque et les opérations numériques. Les décisions de gouvernance relatives à cet actif méritent la même attention de la part des dirigeants que n’importe quel autre système de production ayant une influence directe sur la continuité des activités et la résilience de l’organisation.

Les organisations qui parviennent systématiquement à gérer WordPress en toute sécurité sont rarement celles qui disposent des technologies les plus sophistiquées. Ce sont celles qui se caractérisent par une responsabilité clairement définie, des processus opérationnels rigoureux, une obligation de rendre compte mesurable et une direction qui considère la gouvernance comme une compétence stratégique de l’entreprise plutôt que comme un aspect technique secondaire.

En conclusion

La sécurisation de WordPress n’est pas difficile en soi. Ce qui rend la tâche difficile, c’est le manque de cohérence dans la gestion de la sécurité.

Les organisations investissent souvent massivement dans de nouvelles technologies de sécurité, tout en négligeant les pratiques opérationnelles qui permettent de réduire les risques au quotidien. Une responsabilité clairement définie, une gestion rigoureuse des correctifs, un contrôle des dépendances vis-à-vis des tiers, une gouvernance stricte des accès et des processus de reprise testés garantissent systématiquement de meilleurs résultats en matière de sécurité que le simple fait d’ajouter davantage d’outils.

Pour les dirigeants d’entreprise, la discussion ne doit pas porter en premier lieu sur la prochaine faille de sécurité ou sur le dernier produit de sécurité en date. Elle doit commencer par la question de la responsabilité. Qui approuve les nouveaux plugins ? Qui est chargé de prendre les décisions relatives aux correctifs ? Qui vérifie les droits d’accès des administrateurs ? Qui est responsable de la restauration du site en cas de compromission ? Si les réponses à ces questions ne sont pas claires, le niveau de sécurité de l’organisation est déjà plus faible qu’il n’y paraît.

C’est également l’occasion de simplifier les choses. Chaque plugin inutile supprimé, chaque compte administrateur obsolète désactivé, chaque environnement d’exécution non pris en charge mis à niveau et chaque lacune en matière de gouvernance comblée permet de réduire la complexité opérationnelle tout en améliorant la résilience. Les environnements plus simples sont généralement plus faciles à sécuriser, à auditer et à exploiter à grande échelle.

La sécurité doit également être considérée comme une capacité opérationnelle permanente plutôt que comme une série de projets techniques isolés. Les menaces évoluent, les priorités opérationnelles changent et les équipes s’agrandissent au fil du temps. La gouvernance apporte la cohérence qui permet aux organisations de s’adapter sans que les risques ne s’accumulent à leur insu.

En fin de compte, les dirigeants ont un choix stratégique à faire. Ils peuvent gérer WordPress selon les mêmes normes que celles appliquées à tous les autres systèmes de production, ou bien accepter en toute connaissance de cause les risques opérationnels et commerciaux liés à une approche différente. Ce qu’il faut éviter, c’est la voie du compromis, où les responsabilités sont fragmentées, où la propriété n’est pas clairement définie et où la sécurité devient réactive.

Les organisations qui protègent systématiquement leurs environnements WordPress se distinguent rarement par des budgets de sécurité particulièrement élevés. Elles se démarquent parce que leurs dirigeants ont défini des responsabilités claires, normalisé les pratiques opérationnelles et intégré la gouvernance dans le fonctionnement courant de l’organisation. Cette approche réduit les risques de sécurité et renforce la résilience, favorise la conformité et permet aux équipes de consacrer davantage d’énergie à la création de valeur pour l’entreprise.