Faut-il un pare-feu pour WordPress, ou un scanner de logiciels malveillants suffit-il ?

Un pare-feu et un scanner n'ont pas le même travail, et la plupart des sites WordPress sont mieux protégés avec les deux. Un pare-feu examine chaque requête avant que WordPress la traite et refuse celles qui ressemblent à une attaque. Un scanner examine ce qui se trouve déjà sur le site : fichiers, comptes, réglages et versions des extensions. Un pare-feu ne peut pas vous dire que quelqu'un a installé une porte dérobée le mois dernier. Un scanner ne peut pas arrêter la requête qui l'installe.

Le pare-feu n'a pas besoin d'être une extension WordPress. Pour beaucoup de petits sites, il vient de l'hébergeur ou d'un CDN placé devant le site.

Ce que fait un pare-feu applicatif web

Un pare-feu applicatif web (WAF) se place entre le visiteur et votre site. Pour chaque requête, il compare l'adresse, les paramètres, les champs de formulaire et les en-têtes à un ensemble de règles, puis bloque la requête, la ralentit ou la laisse passer. Les règles typiques repèrent les tentatives d'injection SQL et de cross-site scripting, les requêtes vers des fichiers d'extensions ayant des failles connues, les rafales de tentatives de connexion et les robots malveillants.

Il peut fonctionner à trois endroits :

• En périphérie, dans un CDN ou un proxy inverse par lequel passe tout le trafic. Une requête bloquée n'atteint jamais votre serveur, elle ne lui coûte donc rien.
• Sur le serveur, comme module du serveur web que l'hébergeur exécute pour chaque site qu'il héberge.
• Dans WordPress, comme extension. Elle ne voit une requête qu'une fois arrivée sur votre serveur et PHP démarré, et elle consomme le processeur et la mémoire de votre hébergement à chaque requête. En contrepartie, elle connaît WordPress : qui est connecté, et à quelle extension appartient une adresse.

Ce qu'un pare-feu ne sait pas faire

Un pare-feu juge les requêtes une par une, selon des règles. Certaines failles restent ouvertes quel que soit l'ensemble de règles :

• Une connexion avec un mot de passe volé mais valide ressemble au propriétaire qui se connecte.
• Une faille dans une extension pour laquelle personne n'a encore écrit de règle passe à travers. Les règles suivent les vulnérabilités publiées, il y a donc toujours une fenêtre.
• Le code déjà présent sur le serveur continue de s'exécuter. Un pare-feu installé après une intrusion ne supprime pas la porte dérobée.
• Les modifications faites depuis un compte administrateur, y compris un compte détourné, sont du trafic ordinaire pour un pare-feu.

C'est pourquoi les mises à jour passent en premier. Une règle de pare-feu pour une faille connue fait gagner du temps jusqu'à la mise à jour. Elle ne la remplace pas.

Ce que fait un scanner de logiciels malveillants

Un scanner vérifie l'état du site. Un bon scanner pour WordPress :

• compare les fichiers de WordPress, des extensions et des thèmes avec les copies officielles de WordPress.org pour votre version, ce qui repère les fichiers modifiés sans deviner,
• cherche des fichiers PHP dans le dossier des téléversements,
• liste les comptes administrateurs et remarque les nouveaux,
• compare les versions des extensions et des thèmes avec les vulnérabilités publiées,
• trouve les sauvegardes et les copies de la configuration que n'importe qui peut télécharger.

Il n'arrête rien pendant une attaque. Il vous dit après coup ce qui a changé et ce qu'il faut faire. La lecture de ces résultats est traitée dans comment vérifier qu'un site n'a pas de logiciel malveillant.

D'où peut venir un pare-feu

Votre hébergeur. Beaucoup d'hébergeurs filtrent les requêtes de tous les sites de leurs serveurs. Demandez-lui par écrit : y a-t-il un pare-feu applicatif web devant mon site, qui met à jour ses règles, et puis-je voir ce qu'il a bloqué ? Si la réponse est oui, vous n'avez peut-être pas besoin d'une autre couche.

Un CDN devant le site. Un CDN comme Cloudflare se place entre les visiteurs et votre serveur et peut filtrer les requêtes en périphérie. Le 19 octobre 2026, la documentation du WAF de Cloudflare (en anglais) indiquait que son Free Managed Ruleset est disponible sur toutes les offres Cloudflare et couvre les vulnérabilités à fort impact et largement exploitées. Une fois le CDN en place, vérifiez deux choses. Votre serveur ne doit pas répondre aux requêtes qui contournent le CDN et vont directement à son adresse IP. La protection de votre connexion doit voir l'adresse du visiteur, pas celle du CDN.

Une extension de pare-feu. C'est la solution quand l'hébergeur n'offre rien et qu'un CDN ne convient pas. Avant d'en choisir une, cherchez dans sa fiche ou sa documentation :

• si elle se charge avant les autres extensions, pour voir la requête avant le code vulnérable,
• à quelle fréquence ses règles sont mises à jour, et si les utilisateurs gratuits reçoivent les nouvelles règles en même temps que ceux qui paient,
• un mode d'apprentissage ou d'enregistrement seul, pour voir ce qu'elle bloquerait avant qu'elle commence à bloquer,
• son effet sur votre serveur. Mesurez le temps de chargement avant, puis un jour après.

Gardez un pare-feu par couche. Deux extensions de pare-feu sur un même site font deux fois le même travail, et quand un client est refusé, il est difficile de savoir laquelle l'a fait.

Duquel avez-vous besoin

• Votre hébergeur filtre-t-il déjà les requêtes ? Alors un scanner et de bonnes habitudes couvrent le reste.
• Gérez-vous une boutique, un espace membres ou des formulaires utilisés par beaucoup de monde ? Un pare-feu en périphérie a du sens, car il y a plus à attaquer et plus à perdre.
• Mettez-vous les extensions à jour dans les jours qui suivent leur publication ? Alors un pare-feu n'attrape surtout que du bruit. Si les mises à jour attendent des semaines, il couvre précisément ce délai.
• Sauriez-vous si un fichier du serveur a changé cette nuit ? Sinon, il vous faut un scanner quoi que vous ayez d'autre.

Aucun des deux ne remplace une sauvegarde conservée hors du serveur. Après une intrusion, c'est une copie saine qui remet le site en état.

Ce qui demande de la vigilance

• Les faux blocages. Un pare-feu qui refuse les rappels de votre prestataire de paiement ou les messages du formulaire de contact vous fait perdre des commandes, sans afficher d'erreur. Lisez son journal pendant les premières semaines.
• Un pare-feu comme prétexte pour reporter les mises à jour. La règle peut arriver après l'attaque.
• Un « nettoyage » promis dans une offre. Supprimer un logiciel malveillant est un travail sur les fichiers, fait par quelqu'un qui les lit. Demandez qui le fait et comment il découvre par où l'attaquant est entré. Sinon, la même porte reste ouverte.

La place d'Ensomedia Security

Ensomedia Security est surtout un scanner avec une protection de la connexion et des interrupteurs de renforcement. Depuis la version 1.1.26, elle a aussi un Pare-feu des requêtes, désactivé tant que vous ne l'activez pas. Ce sont des règles locales sur votre serveur, pas un WAF dans le cloud, et elle ne nettoie pas un site piraté.

Voici comment il se situe par rapport à la liste ci-dessus 

• Il se charge tôt. Un fichier de type must-use examine chaque requête avant le chargement des extensions ordinaires. Chez les hébergeurs qui exécutent PHP en CGI ou FastCGI, le réglage Charger avant WordPress le lance avant WordPress grâce au fichier .user.ini.
• Ses règles arrivent avec les mises à jour de l'extension et sont les mêmes pour tous les sites, car l'extension n'a pas de version payante. Elles couvrent les injections courantes et l'envoi de fichiers exécutables, les blocages par IP, plage d'adresses et pays, les limites de requêtes et d'erreurs 404, et des exceptions étroites. Derrière Cloudflare, le blocage par pays fonctionne avec les plages d'adresses de Cloudflare que l'extension fournit depuis la version 1.1.28. Le trafic ordinaire (la commande WooCommerce, l'éditeur de blocs, l'API REST, les commentaires, les formulaires de contact et la connexion) est couvert par des tests et passe avec toutes les règles actives.
• Il a un mode Journaliser seulement. Commencez par lui, lisez l'historique du pare-feu pendant une ou deux semaines, puis passez à Bloquer.
• Il tourne sur votre serveur, donc une requête bloquée a déjà atteint votre hébergement et lancé PHP. Il ne soulage pas le serveur comme un filtre en bordure de réseau. Il n'envoie aucune donnée de requête à l'extérieur, et son historique reste sur votre site 30 jours au plus.

Un pare-feu chez l'hébergeur ou dans un CDN et celui-ci travaillent à des niveaux différents et peuvent donc fonctionner ensemble. Ne l'utilisez pas à côté d'une autre extension de pare-feu. S'il vous bloque un jour, la FAQ de l'extension explique comment le désactiver sans passer par le tableau de bord.

Ce qu'elle fait en plus 

• Elle vérifie d'abord les sommes de contrôle officielles. Le cœur de WordPress, les extensions et les thèmes du répertoire sont comparés aux fichiers que WordPress.org a publiés pour votre version.
• Elle ne réécrit jamais le site toute seule. Les fichiers, les utilisateurs et les réglages ne changent que lorsque vous appuyez sur un bouton ou activez un interrupteur. Un fichier avec un constat de gravité moyenne ou supérieure peut être mis en quarantaine d'un bouton, et Restaurer le remet en place. Depuis la version 1.1.21, un bouton remplace un fichier modifié du cœur, d'une extension ou d'un thème par son original de WordPress.org et garde le fichier modifié en quarantaine, de sorte que le restaurer annule la réparation. Depuis la version 1.1.25, elle retire aussi le code injecté dans un thème, une extension sur mesure, le dossier uploads, les articles ou les options 
  elle montre la modification exacte, fait une sauvegarde et ne l'applique qu'avec votre accord, et chaque nettoyage peut être annulé. Tout autre nettoyage qu'elle explique revient à vous, à votre développeur ou à votre hébergeur.
• Elle limite les connexions échouées par adresse et par nom d'utilisateur. Seule compte l'adresse de la connexion elle-même, jamais un en-tête qu'une requête peut falsifier. Derrière un CDN ou un proxy, vous indiquez ses adresses comme proxys de confiance et choisissez l'en-tête qui porte l'adresse du visiteur.
• Depuis la version 1.1.27, elle propose des vérifications de connexion facultatives 
  connexion avec une clé d'accès sans mot de passe, vérification anti-bot à la connexion, à l'inscription et à la réinitialisation du mot de passe, refus des mots de passe issus de fuites de données, adresse de connexion masquée et pièges à spam pour les commentaires, les inscriptions et les formulaires de contact. Toutes restent désactivées tant que vous ne les activez pas.
• Elle propose des interrupteurs de renforcement, tous désactivés tant que vous ne les activez pas : l'éditeur de fichiers, XML-RPC, un blocage de PHP dans les téléversements et les en-têtes de sécurité. Un en-tête que votre serveur, votre CDN ou une autre extension envoie déjà est laissé tel quel.
• Elle propose des correctifs virtuels, volontairement étroits. Avec le flux de menaces en temps réel activé, un petit fichier de type must-use peut arrêter une requête qui exploite une vulnérabilité connue d'une extension que vous avez installée, aussi longtemps que votre version installée est concernée. Les correctifs bloquent si vous acceptez, après l'activation, la proposition d'activer la protection. Sinon, ils se contentent d'enregistrer les requêtes correspondantes. Elle n'inspecte pas tout le trafic comme le fait un pare-feu.

Les tests, l'analyse quotidienne planifiée et les alertes par e-mail sont gratuits, sans compte et sans limites. Le pare-feu, les vérifications de connexion, le flux de menaces en temps réel, la recherche de vulnérabilités et le second avis de l'IA restent désactivés tant que vous ne les activez pas. Vous trouverez l'extension dans le répertoire WordPress.org sous le nom Ensomedia Security, et la page de l'extension liste ce qu'envoie chaque service optionnel. Une comparaison côte à côte avec Wordfence, avec ce que chaque extension a et n'a pas, se trouve sur la page de comparaison (en anglais).

Vérifiez votre site depuis l'extérieur. Saisissez votre adresse sur shieldwave.io. Cela prend environ 90 secondes, sans mot de passe et sans extension.