Sécuriser les extensions tierces WordPress

Un CMS (Content Management System, système de gestion de contenu) largement déployé concentre code métier, comptes administrateurs, données personnelles, formulaires publics et dépendances maintenues par des tiers. L’extension tierce est le compromis central : elle accélère une fonctionnalité, mais elle introduit du code, des droits et une cadence de correction qui échappent partiellement à l’exploitation.

→ Lire l’explication complète de la marmotte

Le choix recommandé est brutal : réduire le catalogue d’extensions à celles qui possèdent un propriétaire, une justification métier et un cycle de maintenance vérifiable. Une extension inactive reste du code exécutable accessible à une erreur future, pas un souvenir attendrissant dans l’interface d’administration. La désactiver ne suffit pas, il faut la supprimer.

Cette fiche ne traite pas des failles d’upload de fichiers. L’upload est une voie d’exécution particulière ; les extensions élargissent, elles, presque toutes les frontières du CMS : authentification, administration, API, base de données, rendu HTML et tâches planifiées.

Inventaire des extensions et dette de dépendances

Un CMS n’est pas un produit monolithique. WordPress charge son noyau, son thème actif, les extensions actives, parfois des extensions réseau dans une installation multisite, puis les bibliothèques embarquées par chacun. Deux extensions peuvent inclure des versions différentes de la même bibliothèque PHP (Hypertext Preprocessor, préprocesseur hypertexte), sans mécanisme de résolution central. Le gestionnaire de paquets moderne est resté dehors, probablement à remplir une slide de stratégie.

L’inventaire doit contenir, pour chaque extension, sa version, son origine, son hachage, son propriétaire fonctionnel, son propriétaire technique, les privilèges requis et les points d’exposition : page d’administration, shortcode, formulaire public, tâche planifiée, route REST (Representational State Transfer, style d’interface web) ou appel externe. Sans cette liste, la gestion de vulnérabilités se réduit à chercher le nom d’un greffon dans un tableur. Ce n’est pas de la gouvernance, c’est de l’archéologie sous contrainte de délai.

Une extension téléchargée hors du dépôt officiel, distribuée dans un thème premium ou modifiée localement doit être classée comme dépendance interne. La vérification automatique de version ne couvre alors plus le code réellement exécuté. Le même traitement s’applique aux extensions abandonnées : absence de correctif, absence de responsable, retrait programmé. Garder une extension non maintenue au motif qu’elle fonctionne revient à déclarer qu’un défaut non corrigé a droit à une carrière.

Avant déploiement, prévoir :

une version de PHP supportée simultanément par le CMS, les extensions retenues et l’hébergement ;
une base de données sauvegardable et restaurable de manière testée ;
un environnement de préproduction représentatif, incluant les extensions payantes et leurs clés de licence ;
un mécanisme d’authentification forte pour les comptes d’administration ;
une chaîne de mise à jour capable de produire un artefact identifié, plutôt qu’une modification manuelle sur le serveur ;
un journal centralisé des connexions, changements d’extensions, élévations de privilèges et erreurs applicatives.

L’architecture cyber doit traiter le CMS comme une application Internet, pas comme une vitrine statique avec un bouton de publication. Une vitrine statique ne lance pas de code venant de quinze éditeurs différents à chaque requête. Heureusement pour elle.

Frontières de confiance des extensions WordPress

Une extension PHP exécutée dans WordPress hérite généralement des droits du processus PHP. Si ce processus peut lire wp-config.php, se connecter à la base de données et écrire dans certains répertoires, l’extension le peut aussi. Les contrôles de capacité de WordPress limitent les actions des utilisateurs, pas les possibilités intrinsèques du code chargé par le serveur.

La frontière à surveiller en premier est donc l’administration. Une vulnérabilité d’autorisation survient lorsqu’une action sensible vérifie seulement qu’un utilisateur est connecté, ou ne vérifie aucun droit. Les fonctions de contrôle de capacité doivent précéder toute modification d’option, toute exportation et toute action administrative. Un nonce WordPress protège contre le CSRF (Cross-Site Request Forgery, requête forcée intersite), mais ne remplace pas une vérification d’autorisation : un nonce valide obtenu par un contributeur ne lui donne pas le droit de créer un administrateur.

Les routes REST et les points admin-ajax.php méritent un inventaire distinct. Une route enregistrée sans contrôle d’autorisation exploitable expose souvent une lecture de données, une modification de configuration ou une création d’objets. Les paramètres doivent être validés selon leur type et leur plage avant d’atteindre une requête SQL (Structured Query Language, langage de requête structuré), une fonction de fichier ou un appel HTTP. Échapper une valeur à l’affichage ne protège pas une requête SQL ; chaque frontière a son poison préféré.

L’injection SQL résulte d’une concaténation de données contrôlées dans une requête. Le correctif est l’usage systématique de requêtes préparées, pas un filtre maison composé à 23 h 47. La XSS (Cross-Site Scripting, injection de script intersite) survient lorsqu’une extension rend du contenu non fiable sans encodage adapté au contexte HTML, JavaScript ou URL. Son impact devient critique si un administrateur consulte la page piégée : le navigateur de l’administrateur porte déjà ses permissions.

Les intégrations externes ajoutent une autre frontière. Une extension de statistiques, de formulaire ou de paiement peut transmettre adresses électroniques, contenus soumis et jetons d’accès à un service tiers. La clé d’interface de programmation ne doit jamais être stockée dans une option WordPress accessible à tout administrateur si elle ouvre d’autres environnements. La séparer dans le gestionnaire de secrets de la plateforme, avec un droit de lecture limité au processus concerné, réduit la portée d’une compromission. Les principes détaillés dans la rubrique identités s’appliquent ici aussi : une identité applicative doit avoir un rôle mesurable, pas des droits globaux par fatigue administrative.

Durcissement du cycle de mise à jour

Activer les mises à jour automatiques pour toutes les extensions n’est pas une politique de sécurité, c’est une délégation de changement sans filet. Les désactiver complètement est pire : les vulnérabilités publiées restent alors exploitables jusqu’au prochain grand ménage, généralement après l’incident. Le compromis retenu doit dépendre de la criticité et de la capacité de retour arrière.

Pour les extensions exposées publiquement, appliquer les correctifs de sécurité après passage automatisé en préproduction et validation des fonctions critiques. Pour les extensions qui modifient l’authentification, le paiement, les en-têtes HTTP ou le cache, promouvoir un artefact testé avec fenêtre de retour arrière. Le délai acceptable dépend de l’exposition : une extension qui fournit un formulaire public n’a pas le même budget de risque qu’un générateur de sitemap isolé.

Un WAF (Web Application Firewall, pare-feu applicatif web) peut filtrer des charges connues et réduire le bruit d’exploitation opportuniste. Il ne corrige ni une autorisation absente, ni une fuite de données par route légitime, ni un administrateur compromis. Le présenter comme rustine temporaire est défendable ; le vendre comme correction définitive relève du théâtre de sécurité, avec pare-feu en carton et projecteur bien orienté.

Réduire aussi l’exposition structurelle :

désinstaller extensions et thèmes inutilisés, y compris les thèmes par défaut non nécessaires ;
interdire l’éditeur de fichiers depuis l’administration ;
rendre le système de fichiers non inscriptible par le processus web hors répertoires strictement nécessaires ;
limiter l’accès administratif par réseau, identité fédérée ou authentification multifacteur ;
séparer les comptes d’administration du CMS des comptes de publication courante ;
restreindre les clés d’interface tierces par origine, privilège et environnement ;
bloquer les sorties réseau non nécessaires, après inventaire des appels légitimes.

Exemple de contrôle reproductible avec WP-CLI

WP-CLI (WordPress Command Line Interface, interface en ligne de commande WordPress) permet de capturer l’état des extensions et de vérifier les contrôles d’intégrité disponibles pour celles issues du dépôt officiel. L’exécution doit se faire avec un compte système capable de lire l’installation, mais pas avec le compte root. Lancer l’administration applicative en super-utilisateur est une tradition tenace, au même titre que stocker les mots de passe dans des fichiers nommés final-v2.

# Se placer dans la racine WordPress et inventorier les extensions installées.
wp plugin list --format=csv > plugins-inventaire.csv

# Vérifier les sommes publiées pour les extensions provenant du dépôt officiel.
# Une divergence doit être analysée : correctif local, compromission ou erreur de déploiement.
wp plugin verify-checksums --all

# Désactiver puis supprimer une extension retirée du catalogue approuvé.
# Remplacer ancien-plugin par le slug réellement inventorié.
wp plugin deactivate ancien-plugin
wp plugin delete ancien-plugin

# Interdire l'édition de code depuis l'interface WordPress.
# Ajouter cette constante dans wp-config.php via le mécanisme de configuration géré.
# define('DISALLOW_FILE_EDIT', true);

Ce contrôle ne valide pas une extension commerciale, une archive interne ou une modification locale. Pour ces cas, produire un hachage SHA-256 (Secure Hash Algorithm 256 bits) de l’archive approuvée, le conserver avec l’artefact de déploiement et comparer le contenu installé avant promotion. Un hachage confirme l’identité d’un fichier attendu, pas l’absence de vulnérabilité. Confondre les deux donne des audits très propres sur papier et des incidents tout aussi réels.

Détection, sauvegarde et reprise après compromission

La supervision doit corréler les événements du CMS avec ceux du serveur web et de l’identité : échecs d’authentification, création de comptes administrateurs, activation d’extensions, modification de réglages, appels anormaux aux routes REST et erreurs PHP répétées. Une extension compromise cherche souvent la persistance : nouveau compte, tâche planifiée, fichier ajouté dans un répertoire inscriptible ou clé d’interface exportée.

L’alerte la plus rentable concerne les changements administratifs hors fenêtre de maintenance. Il faut aussi surveiller les requêtes sortantes du processus PHP vers des domaines inconnus, surtout après une mise à jour d’extension. Une communication sortante n’est pas automatiquement malveillante, mais une extension de galerie qui contacte un domaine éphémère à intervalles fixes mérite plus qu’un haussement d’épaules.

La sauvegarde doit inclure les fichiers applicatifs, la base de données et la configuration externe nécessaire au redémarrage. Une sauvegarde de base seule restaure les contenus et les comptes, mais pas forcément le code introduit par une extension compromise. À l’inverse, restaurer les fichiers sans la base peut réintroduire des options ou comptes malveillants encore présents dans les données.

En cas de compromission confirmée, isoler l’instance, préserver journaux et copies pour analyse, révoquer les mots de passe, jetons et clés accessibles au processus compromis, puis reconstruire depuis des artefacts approuvés. Restaurer directement un serveur infecté est une reprise de service, pas une éradication. Les vulnérabilités publiques et leur traitement doivent être suivis avec la même discipline que les autres failles applicatives : identifier l’actif, qualifier l’exposition, corriger, vérifier, documenter l’écart.

Un CMS durci ne garantit pas l’absence de défaut dans une extension, ni la loyauté durable de son éditeur, ni la sécurité d’un compte administrateur volé. Le reste vient de la segmentation réseau, de la gestion des identités, de la journalisation, de la capacité à reconstruire et d’une gouvernance qui sait retirer une fonctionnalité devenue trop chère à défendre.

🐝 Ce qui arrive si on s’en passe

Sans catalogue haché des extensions approuvées, aucune référence ne permet de dater l’arrivée d’un fichier étranger. L’analyse ne sait pas quelle sauvegarde précède l’injection, et la reprise risque de restaurer une copie déjà piégée, ce qui réactive la persistance au redémarrage. Sans interdiction de l’éditeur intégré et avec un système de fichiers inscriptible, une session administrateur volée ne reste pas un problème applicatif : elle devient une écriture de code PHP sur le serveur, puis une lecture de wp-config.php et des identifiants de base, hors de portée des contrôles de capacité. Dans une installation multisite, une extension activée au niveau réseau sans propriétaire étend enfin un défaut unique à tous les sites hébergés, qui partagent la même base et les mêmes comptes de super-administration.

🦫 Explication de la marmotte 🍫

Un système de gestion de contenu permet de publier et modifier un site depuis une interface web. Les extensions ajoutent des fonctions, par exemple des formulaires, des statistiques ou des paiements. Elles ajoutent aussi du programme exécuté sur le serveur, avec souvent les mêmes accès que le site principal : lire la configuration, consulter la base de données et modifier certains fichiers.

Une attaque peut commencer par un défaut dans une extension. Si elle ne vérifie pas les droits d’une personne connectée, cette personne peut parfois changer un réglage réservé aux administrateurs. Si elle accepte une donnée sans contrôle, cette donnée peut modifier une requête vers la base de données ou exécuter du code dans le navigateur d’un administrateur. Une mise à jour peut corriger le défaut, mais elle peut aussi modifier le fonctionnement du site. Il faut donc tester avant de l’installer, puis pouvoir revenir à la version précédente si elle casse une fonction attendue.

La protection commence par supprimer les extensions inutilisées et choisir celles qui sont maintenues. Les comptes d’administration doivent être protégés par une seconde preuve d’identité. Les changements doivent être enregistrés pour repérer une activation inhabituelle ou la création d’un compte. Enfin, les sauvegardes doivent contenir les données et les fichiers, puis être testées : une copie jamais restaurée est seulement une promesse rangée dans un placard.

Pages voisines

La citent

Sécuriser les extensions tierces WordPress

Elle cite

: les deux pages se citent l’une l’autre.

Sécuriser les extensions tierces WordPress

Sécuriser les extensions tierces WordPress

Inventaire des extensions et dette de dépendances

Frontières de confiance des extensions WordPress

Durcissement du cycle de mise à jour

Exemple de contrôle reproductible avec WP-CLI

Détection, sauvegarde et reprise après compromission

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines