Le WordPress d'aujourd'hui, décodé pour les développeurs

Sécurité

Revue de code sécurité d’une extension avant sa mise en production : la grille utilisée en agence

Valider le travail d'un prestataire externe avant sa mise en ligne suit rarement une improvisation. Une grille de points de contrôle génériques rend cette revue reproductible.

Par WordPress Développement • 23 août 2022 • 4 min de lecture • Aucun commentaire
Revue de code sécurité d'une extension avant sa mise en production : la grille utilisée en agence

Une extension livrée par un prestataire externe, avant sa mise en production sur un site existant, mérite une revue de sécurité qui ne repose pas sur l’intuition du relecteur du jour. Une grille de points de contrôle écrite, appliquée systématiquement, produit une revue reproductible d’un projet à l’autre, indépendamment de la personne qui la mène.

Famille 1 : l’échappement des sorties

  • Chaque variable affichée dans un gabarit HTML passe-t-elle par esc_html(), esc_attr() ou une fonction d’échappement adaptée à son contexte d’affichage précis ?
  • Le contenu riche autorisant du HTML limité passe-t-il par wp_kses() avec une liste de balises explicitement définie, plutôt que par un affichage brut ou un wp_kses_post() appliqué par réflexe sans vérifier sa pertinence ?
  • Les attributs d’URL générés dynamiquement passent-ils par esc_url(), y compris pour des liens internes considérés comme fiables par défaut ?

Famille 2 : la validation et la sanitisation des entrées

  • Chaque valeur issue de $_GET, $_POST ou d’un paramètre de route REST passe-t-elle par une fonction de sanitisation adaptée à son type attendu avant tout traitement ?
  • Les types de données reçus sont-ils vérifiés explicitement, notamment pour éviter qu’un tableau injecté ne soit traité comme une chaîne de caractères par erreur ?
L'essentiel à retenir : L'échappement des sorties se vérifie fichier par fichier, pas globalement ; Les nonces et capacités doivent couvrir chaque action de modification ; Une revue reproductible s'appuie sur une grille écrite, pas sur la mémoire du relecteur

Famille 3 : les nonces et la protection contre les soumissions forgées

  • Chaque formulaire qui modifie une donnée inclut-il un nonce généré par wp_nonce_field(), vérifié côté serveur par wp_verify_nonce() ou check_admin_referer() avant tout traitement ?
  • Les routes de l’API REST qui modifient une donnée déclarent-elles un permission_callback qui ne se contente pas de __return_true par commodité ?

Famille 4 : les capacités et le principe de moindre privilège

  • Chaque action sensible vérifie-t-elle une capacité précise via current_user_can(), plutôt qu’une simple vérification de connexion de l’utilisateur ?
  • Les capacités personnalisées introduites par l’extension sont-elles documentées et attribuées à des rôles cohérents avec leur niveau de sensibilité réel ?

Famille 5 : les requêtes à la base de données

  • Toute requête SQL construite dynamiquement passe-t-elle par $wpdb->prepare(), y compris dans une clause LIKE où esc_like() doit également intervenir ?
  • Aucune valeur utilisateur n’est-elle concaténée directement dans une chaîne de requête, même pour un usage jugé interne ou peu exposé ?

Famille 6 : les dépendances et les appels externes

  • Les bibliothèques tierces embarquées sont-elles à jour, et leur origine vérifiable via un dépôt public reconnu ?
  • Tout appel réseau sortant vers un service tiers passe-t-il par une fonction qui valide le domaine de destination, plutôt que par une URL entièrement dérivée d’une entrée utilisateur ?

Une grille de revue n’a de valeur que si elle est appliquée intégralement à chaque projet, y compris ceux jugés simples ou de faible enjeu apparent.

Comment exploiter cette grille en pratique

Chaque point de contrôle donne lieu à une réponse binaire, conforme ou non conforme, avec un exemple précis de la ligne de code concernée en cas de non-conformité. Cette traçabilité permet de renvoyer un rapport de revue exploitable directement par le prestataire, plutôt qu’un avis général difficile à transformer en correctifs concrets. Un projet qui échoue sur plusieurs familles à la fois mérite une nouvelle revue complète après correction, plutôt qu’une validation partielle des seuls points corrigés.

Le temps à prévoir pour une revue sérieuse

Une extension de taille modeste, quelques milliers de lignes réparties sur une dizaine de fichiers, demande généralement une demi-journée de revue attentive pour couvrir les six familles de points de contrôle avec un niveau de rigueur exploitable. Réduire ce temps en se limitant à une lecture superficielle des points les plus visibles, comme l’échappement des sorties, au détriment des points plus discrets comme les capacités ou les appels externes, produit une revue incomplète qui rassure sans réellement protéger.

Pour aller plus loin

Cette grille couvre les points de contrôle génériques applicables à la quasi-totalité des extensions WordPress. Une extension qui manipule un domaine spécifique, comme un moyen de paiement ou une gestion de compte utilisateur avancée, appelle des points de contrôle additionnels propres à ce domaine, à ajouter à cette base commune plutôt qu’à la remplacer.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi