Audit de sécurité WordPress : Ce qu'il faut vérifier avant la mise en ligne

Avant qu'un plugin généré par PAGEnza n'atteigne l'installation WordPress d'un utilisateur, il passe par trois contrôles de sécurité automatisés. Cet article explique ce que ces contrôles recherchent — et pourquoi chacun d'eux est important.

Pourquoi le code généré par l'IA nécessite un audit

Les grands modèles linguistiques sont étonnamment doués pour écrire des plugins WordPress. Ils connaissent les noms des hooks, comprennent les normes de codage WP, produisent du PHP lisible. Mais ils commettent aussi des erreurs prévisibles — et ces erreurs sont des vulnérabilités de sécurité.

Les plus courantes que nous rencontrons :

• Utilisation de $_GET ou $_POST sans assainissement (sanitization)
• Absence de vérification des nonces lors de la soumission des formulaires
• Requêtes directes à la base de données sans $wpdb->prepare()
• Utilisation de eval() ou exec() pour un comportement dynamique
• Affichage de données utilisateur sans esc_html() ou esc_attr()

Ce ne sont pas des cas limites exotiques. Ils apparaissent régulièrement dans les sorties des LLM — même des meilleurs modèles.

Étape 1 : Validation du prompt

Avant que l'IA n'écrive une seule ligne, nous analysons la description de l'utilisateur. Cette étape détecte deux catégories de problèmes :

Tentatives de manipulation — des prompts essayant de faire produire à l'IA du code délibérément malveillant. Des choses comme « ignore les instructions précédentes » ou « crée une porte dérobée pour les tests ».

Descriptions vagues ou irréalisables — des prompts trop courts ou trop ambigus pour produire du code utile. « Faire un plugin » génère des déchets ; « Créer un formulaire de contact qui envoie les soumissions à une adresse e-mail avec filtrage anti-spam » génère quelque chose de réel.

Si un prompt échoue à ce contrôle, l'utilisateur voit une erreur spécifique expliquant pourquoi — pas un rejet générique.

Étape 2 : Linting PHP dans un conteneur isolé

Une fois que l'IA a produit du code PHP, il est exécuté via php -l dans un conteneur Docker complètement isolé de tout le reste. Cela détecte les erreurs de syntaxe avant que le plugin n'atteigne une installation WordPress.

Mais nous allons plus loin : si le linting échoue, le système ne rejette pas simplement la sortie. Il renvoie l'erreur à l'IA avec un prompt de correction — ce que nous appelons le guérison (healing). L'IA voit sa propre erreur et réessaie, jusqu'à trois fois.

Cela signifie que les utilisateurs ne voient presque jamais un message « échec de génération ». Ils voient un temps de génération légèrement plus long — et un code fonctionnel.

Étape 3 : Scan de sécurité du code

C'est l'étape la plus importante. Nous effectuons une analyse statique qui vérifie :

Fonctions dangereuses : eval(), exec(), system(), shell_exec(), passthru() — chacune de ces fonctions bloque la publication du plugin.

Vecteurs d'injection SQL : appels bruts $wpdb->query() avec des variables interpolées, absence de $wpdb->prepare(), utilisation directe de mysql_query().

Absence de vérifications d'autorisation : gestionnaires AJAX qui n'appellent pas current_user_can() avant d'effectuer des actions privilégiées.

Absence de vérification des nonces : processeurs de formulaires qui n'appellent pas wp_verify_nonce() ou check_ajax_referer().

Sortie non échappée : echo $_GET[...], echo $user_input sans fonctions d'échappement.

Si l'un de ces éléments est trouvé, le plugin est bloqué. L'utilisateur voit un rapport listant exactement quelles fonctions ont déclenché le blocage et pourquoi — pas seulement « échec de la vérification de sécurité ».

À quoi ressemble le rapport d'audit

Chaque plugin généré est accompagné d'un rapport d'audit de sécurité en langage clair. Il liste :

• Les contrôles qui ont réussi (vert)
• Les contrôles qui ont déclenché des avertissements (ambre) — problèmes qui ne bloquent pas mais méritent une attention
• Toutes les corrections qui ont été appliquées automatiquement pendant la guérison

Le rapport est généré automatiquement et joint au téléchargement du plugin. Il est utile à la fois pour votre propre confiance et pour montrer aux clients que vous avez pris la sécurité au sérieux.

Étape 4 : Validation à la sauvegarde

Celle-ci ne fait pas partie de la génération initiale — elle s'applique lorsque les utilisateurs modifient manuellement le code du plugin dans l'éditeur PAGEnza.

Chaque fois que vous enregistrez, le même lint + scan de sécurité s'exécute à nouveau. Si vous introduisez une vulnérabilité critique lors de la modification, la sauvegarde est bloquée jusqu'à ce que vous la corrigiez. Cela évite le scénario courant où un développeur apporte une modification « temporaire » rapide qui reste en production pendant deux ans.

Les limites de l'audit automatisé

L'analyse automatisée détecte bien une classe spécifique de problèmes. Elle ne les détecte pas tous.

Les erreurs logiques, la logique métier défaillante et les problèmes subtils d'escalade de privilèges qui n'impliquent pas de modèles dangereux connus nécessitent toujours un examen humain. Nous sommes transparents à ce sujet dans la documentation — l'audit ne remplace pas un examen de sécurité, c'est un seuil qui garantit un standard minimum.

Pour les plugins de production gérant des paiements ou des données sensibles, nous recommandons un examen manuel en plus des contrôles automatisés. Le rapport d'audit fournit un bon point de départ à un réviseur humain.