Principe de fonctionnement

Le plugin introduit un challenge cryptographique exécuté côté client pendant quelques millisecondes. Le navigateur calcule un petit proof‑of‑work (similaire à Hashcash) dont la solution est renvoyée au serveur WordPress. Si la preuve est valide, la soumission est acceptée ; sinon le message est classé comme spam. Le processus est totalement invisible pour l’utilisateur, qui ne voit aucun widget ni aucune case à cocher.

Intégration et détection universelle

Plutôt que d’intercepter les hooks spécifiques de chaque formulaire, le plugin analyse la signature de chaque requête (nom des champs, actions HTTP). Les signatures des constructeurs populaires (Contact Form 7, Elementor, WPForms, Gravity Forms, etc.) sont embarquées et configurées automatiquement à l’activation. Pour un formulaire non répertorié, l’administrateur active le direct analysis mode, soumet le formulaire une fois, puis clique sur « save ». Aucun code supplémentaire n’est requis, ce qui évite les conflits lors des mises à jour des constructeurs.

Analyse de l’impact sur la charge et la sécurité

Le code JavaScript ne pèse que quelques kilooctets et ne bloque pas le rendu, préservant les scores Core Web Vitals. Le calcul du proof‑of‑work consomme une fraction de CPU (généralement 1 ms à 10 ms sur un appareil moderne), mais impose un coût exponentiel aux bots qui doivent répéter l’opération pour chaque message. Le plugin propose également une mode adaptatif : en cas de détection d’une vague de spam, la difficulté du challenge augmente pour tous les visiteurs, puis retombe lorsque l’attaque diminue. En parallèle, il offre une protection contre les tentatives de force brute sur les pages de connexion, avec la possibilité d’alimenter les logs Fail2Ban.

Limites et perspectives

Le modèle repose sur la capacité du client à exécuter du JavaScript. Les appareils très anciens ou les navigateurs désactivés ne pourront pas résoudre le challenge, ce qui pourrait bloquer de légitimes utilisateurs. De plus, des bots dotés de ressources de calcul suffisantes peuvent résoudre le proof‑of‑work, bien que le coût économique reste élevé. Le plugin ne fournit pas de mécanisme de chiffrement asymétrique ni de vérification côté serveur indépendante du calcul client, ce qui limite la résistance face à des attaques ciblées très sophistiquées. Enfin, l’absence d’interaction externe garantit la confidentialité des données, mais empêche toute amélioration basée sur l’apprentissage collectif.