Télécharger les sites web qui utilisent Wordfence Login Security

À propos de Wordfence Login Security

Installer une extension dédiée à la connexion est une décision plus ciblée qu’installer une suite de sécurité, et c’est justement ce caractère ciblé qui constitue le signal. Wordfence Login Security existe parce que certains administrateurs veulent l’authentification à deux facteurs, un CAPTCHA sur la page de connexion et une protection XML-RPC sur WordPress sans adopter en plus un pare-feu et un scanner de logiciels malveillants. Publiée par Defiant Inc. en 2019 sous licence GPL v3 et écrite en PHP, l’extension est le module dissocié d’un produit bien plus vaste, proposé seul à ceux qui ne voulaient que ce module.

Sa présence décrit donc un administrateur qui a un avis sur la question. Soit un produit de sécurité concurrent occupe déjà la place du pare-feu et la surface de connexion restait à couvrir, soit le site est volontairement gardé léger et le propriétaire a choisi le seul contrôle qui répond au trafic de bourrage d’identifiants que reçoit toute installation WordPress, que quelqu’un surveille ou non. Dans les deux cas, l’exploitant est le même type de personne, quelqu’un qui a regardé un journal de connexions et fait un choix délibéré au lieu d’accepter un réglage par défaut. En octobre 2026, nous relevons l’extension sur 1 534 sites.

C’est avec les informations de version qu’une liste d’extensions de sécurité devient intéressante sur le plan opérationnel, et c’est aussi là qu’elle demande la lecture la plus attentive. Sur les installations dont nous parvenons à déterminer la version, 19 versions distinctes apparaissent, et 9.0.1 revient sur une large part d’entre elles. Une dispersion aussi large pour une extension dont toute la raison d’être est le durcissement de l’authentification constitue en soi un constat, car une installation restée à la traîne fait tourner un contrôle d’authentification auquel manquent des correctifs publiés.

Ici, les numéros de version ne sont pas lus dans un panneau d’administration, puisqu’aucun robot d’exploration n’y a accès. La version est déduite des URL de ressources qui la portent en paramètre de requête, des fichiers readme que certaines installations laissent lisibles publiquement, et d’autres empreintes qu’une installation expose sans le vouloir. Un site qui les supprime, ou qui se trouve derrière un cache ou un optimiseur qui réécrit les URL de ressources, n’aboutit à aucune version du tout plutôt qu’à une version erronée. Les 19 versions recensées sont donc celles que l’on peut réellement observer, et la répartition par version couvre une partie des 1 534 sites, et non leur totalité.

Pour un seul domaine, la question est assez simple pour qu’une requête y réponde. Ce site a-t-il mis en place un renforcement de sa connexion ? Les questions de population sont d’une autre nature et ne se construisent pas requête par requête. Quelles plateformes d’hébergement laissent leur parc WordPress sur d’anciennes versions d’extensions ? L’adoption d’une nouvelle version se fait-elle en quelques jours ou en plusieurs trimestres ? Quelle est la taille réelle du marché adressable pour un produit concurrent d’authentification à deux facteurs, et quelle part de ce marché ne paie aujourd’hui rien pour cette fonction ?

Les fournisseurs de sécurité qui évaluent un segment, les chercheurs qui mesurent les pratiques de mise à jour à l’échelle d’un écosystème et les hébergeurs qui vérifient ce que leurs propres clients font réellement tourner ont tous besoin de chaque domaine, de son extension et de la version, quand elle a pu être déterminée, réunis dans un seul fichier. Les tendances en matière d’application des correctifs se dessinent entre les sites plutôt qu’à l’intérieur de l’un d’eux, et c’est exactement le niveau qu’une requête par domaine ne peut pas atteindre.