Revue de sécurité d’une extension avant installation : 15 points

Un client nous a un jour demandé d’installer « juste cette extension, elle est gratuite et bien notée » pour ajouter un formulaire de devis. Quinze minutes de lecture du code plus tard, nous avons trouvé une fonction AJAX qui exécutait eval() sur un champ envoyé par le visiteur. L’extension affichait pourtant quatre étoiles et cinquante mille installations actives.

Les notes et le nombre d’installations ne disent rien de la qualité du code. Nous avons donc fini par formaliser une grille de quinze points, appliquée systématiquement avant d’ajouter une extension sur un site que nous maintenons, qu’elle vienne du répertoire officiel ou d’un dépôt tiers.

Les signaux à vérifier avant même d’ouvrir le code

1. Date de dernière mise à jour : une extension qui n’a pas été mise à jour depuis plus de deux ans sur des versions majeures de WordPress est un signal d’alerte, même si elle « fonctionne encore ».
2. Compatibilité annoncée : vérifiez que la version testée jusqu’à correspond à une version récente du cœur, pas à une version de trois ans.
3. Historique des versions (changelog) : des mentions « security fix » répétées sans détail précis sur ce qui a été corrigé sont un mauvais signe autant qu’un bon, selon la transparence de l’éditeur.
4. Support actif : un tour du forum de support officiel montre si les questions restent sans réponse pendant des mois.
5. Éditeur identifiable : une société ou un développeur identifiable, avec un site et un historique, inspire davantage confiance qu’un pseudonyme isolé sans autre extension publiée.

La lecture du code source proprement dite

Une fois ces signaux vérifiés, place à la lecture du code. Sur une extension de taille raisonnable, on ne lit pas tout : on cherche les points d’entrée dangereux avec une recherche par mots-clés.

1. Recherche de fonctions dangereuses : eval(, base64_decode(, system(, exec(, create_function( associées à des entrées utilisateur sont des drapeaux rouges immédiats.
2. Requêtes SQL directes : toute utilisation de $wpdb->query() sans passer par $wpdb->prepare() mérite un examen attentif de l’origine des données injectées.
3. Points d’entrée AJAX et REST : listez les actions enregistrées via wp_ajax_, wp_ajax_nopriv_ et register_rest_route(), et vérifiez qu’un contrôle de capacité (current_user_can()) protège chacune quand c’est pertinent.
4. Vérification des nonces : les formulaires et actions qui modifient des données doivent utiliser wp_verify_nonce() ou check_admin_referer().
5. Échappement des sorties : une extension qui n’utilise jamais esc_html(), esc_attr() ou esc_url() dans son affichage a de bonnes chances de contenir une XSS quelque part.

Ce que révèle la structure du projet

1. Dépendances tierces embarquées : une bibliothèque JavaScript ou PHP copiée dans le projet, sans mécanisme de mise à jour, vieillit invisible et peut porter ses propres vulnérabilités.
2. Appels réseau sortants : recherchez wp_remote_get(), wp_remote_post() ou curl_init() pour savoir si l’extension envoie des données vers un service tiers, et lequel.
3. Fichiers d’upload et de type MIME : si l’extension gère des envois de fichiers, vérifiez qu’elle contrôle le type réel du fichier et pas seulement son extension déclarée.
4. Désinstallation propre : la présence d’un fichier uninstall.php cohérent montre un minimum de soin apporté au cycle de vie des données.
5. Dépôt public consultable : quand le code est hébergé sur un dépôt public (GitHub notamment), l’historique des commits et des tickets ouverts donne une vue sur la réactivité réelle de l’équipe, au-delà du changelog officiel.

Automatiser une partie du contrôle

Sur les extensions volumineuses, la lecture manuelle complète n’est pas réaliste. Un premier passage avec un outil d’analyse statique PHP, ou une recherche par expressions régulières ciblée sur les fonctions listées ci-dessus, permet de prioriser les fichiers à examiner en détail.

grep -rn "eval(\|base64_decode(\|system(\|exec(" wp-content/plugins/mon-extension/ --include="*.php"

Ce genre de commande ne remplace pas une lecture attentive, mais elle réduit une extension de trois mille lignes à une dizaine de points d’attention concrets.

Ce que cette grille ne remplace pas

Une revue de code avant installation ne dispense pas d’un suivi dans la durée : une extension propre aujourd’hui peut recevoir une mise à jour compromise demain, notamment en cas de rachat par un nouvel éditeur. Cette grille sert à filtrer l’entrée, pas à garantir une sécurité perpétuelle.

Notre règle interne : si un des quinze points échoue franchement, on cherche une alternative avant de discuter avec le client. Le temps perdu à comparer deux extensions coûte toujours moins cher qu’un nettoyage de site piraté.

Notre verdict

Ces quinze points prennent entre quinze et trente minutes sur une extension de taille moyenne, et beaucoup moins sur un simple widget. Ce temps est négligeable comparé à celui d’un incident de sécurité découvert des mois plus tard. La discipline compte plus que la sophistication de l’outillage : une checklist suivie systématiquement vaut mieux qu’un audit ponctuel approfondi mais jamais répété.