Plugin de sécurité WordPress : ce qu'il apporte et ce qu'il alourdit

Un plugin de sécurité WordPress surveille les connexions et les fichiers depuis le tableau de bord d'administration

À la une

Un plugin de sécurité WordPress ajoute en moyenne cinq couches de protection absentes du cœur du CMS, mais il injecte aussi entre 2 et 12 requêtes SQL supplémentaires à chaque chargement de page. Le choix du bon outil dépend donc autant du niveau de menace réel que de la tolérance du serveur en matière de performances.

Environ 13 000 sites WordPress sont piratés chaque jour selon les données publiées par Wordfence dans son rapport annuel 2025. Face à ce constat, installer une extension de sécurité semble évident. Pourtant, chaque fonction activée consomme des ressources serveur. Cet article détaille ce que chaque type de plugin apporte réellement, ce qu’il coûte en temps de réponse, et comment arbitrer sans sacrifier ni la protection ni la vitesse.

Dans cet article

WordPress natif ne couvre que 3 des 8 vecteurs d’attaque les plus courants sur un site vitrine
Un pare-feu applicatif côté serveur ajoute en moyenne 40 à 120 ms au TTFB selon l’hébergement
Les scans de fichiers programmés consomment jusqu’à 80 % du CPU sur un mutualisé pendant leur exécution
Wordfence, Sucuri et SecuPress adoptent trois architectures radicalement différentes
Quatre fonctions de sécurité peuvent être assurées sans aucun plugin via la configuration serveur
Le choix optimal dépend du type d’hébergement et du nombre de visites quotidiennes

Sommaire

Cinq fonctions de sécurité absentes de WordPress natif
Wordfence, Sucuri, SecuPress : trois architectures à distinguer
Entre 2 et 12 requêtes SQL par page : le coût réel sur les performances
Pare-feu côté serveur ou côté cloud : l’impact mesuré sur le TTFB
Quatre protections que l’on peut activer sans extension
Quel plugin choisir selon le profil et l’hébergement du site
Configuration minimale pour protéger sans alourdir le site
Les cinq erreurs qui transforment un plugin de sécurité en problème

Cinq fonctions de sécurité absentes de WordPress natif

WordPress intègre un système de mises à jour automatiques, un salage des mots de passe et une gestion des rôles utilisateurs. En revanche, cinq protections essentielles ne sont pas couvertes par le cœur du CMS et justifient l’ajout d’un outil dédié.

La première est le pare-feu applicatif (WAF). Il filtre les requêtes HTTP avant qu’elles n’atteignent PHP et bloque les tentatives d’injection SQL, de cross-site scripting (XSS) et de traversal de répertoire. Sans WAF, chaque requête malveillante est traitée par le serveur comme une requête légitime, ce qui gaspille des ressources en plus de créer un risque.

La deuxième est la limitation des tentatives de connexion. Par défaut, WordPress autorise un nombre illimité d’essais sur la page wp-login.php. Un plugin de sécurité impose un seuil, par exemple cinq tentatives en dix minutes, puis bloque l’adresse IP. Cette protection est détaillée dans le guide sur les attaques par force brute sur la page de connexion.

La troisième est le scan d’intégrité des fichiers. Le scanner compare chaque fichier du cœur WordPress, des thèmes et des extensions avec les versions officielles du dépôt wordpress.org. Toute modification non autorisée déclenche une alerte. En cas de compromission avérée, la procédure de nettoyage est décrite dans l’article sur les étapes à suivre quand un site WordPress est piraté.

La quatrième est la double authentification (2FA). Aucune fonction native ne permet d’ajouter un second facteur à la connexion administrateur. Les plugins de sécurité intègrent généralement le protocole TOTP (Google Authenticator, Authy). Le sujet est approfondi dans l’article consacré à la double authentification sur l’administration.

La cinquième est la surveillance en temps réel du trafic et des modifications de fichiers, avec notifications par courriel ou via un tableau de bord centralisé. Cette fonction permet de détecter une intrusion dans les minutes qui suivent, plutôt que des semaines après.

Wordfence, Sucuri, SecuPress : trois architectures à distinguer

Les trois extensions les plus utilisées pour sécuriser WordPress adoptent des approches techniques fondamentalement différentes. Le choix entre elles dépend autant de l’architecture souhaitée que du budget disponible.

Wordfence fonctionne entièrement côté serveur. Son pare-feu s’exécute au niveau de PHP, avant le chargement de WordPress. Le scan de malware tourne sur le serveur du site. L’avantage est un contrôle total sans dépendance externe. L’inconvénient est une consommation de ressources directement proportionnelle à la taille du site : sur un hébergement mutualisé, un scan complet peut saturer le CPU pendant plusieurs minutes.

Sucuri déporte le pare-feu dans le cloud. Le trafic passe d’abord par les serveurs de Sucuri, qui filtrent les requêtes malveillantes avant de transmettre le trafic légitime au serveur d’origine. Le serveur n’exécute donc aucune règle de filtrage. En contrepartie, cette architecture ajoute un saut réseau supplémentaire et modifie les enregistrements DNS du domaine, ce qui peut compliquer certaines configurations.

SecuPress, développé en France, combine un pare-feu côté serveur avec une interface orientée vers la simplicité. L’extension propose un score de sécurité global et des correctifs en un clic. Son empreinte mémoire est généralement plus légère que celle de Wordfence, car le scan de fichiers est moins profond par défaut.

Critère	Wordfence (gratuit / pro)	Sucuri (gratuit / pro)	SecuPress (gratuit / pro)
Emplacement du pare-feu	Serveur (PHP)	Cloud (DNS proxy)	Serveur (PHP)
Scan de malware	Local, base signatures	Distant (cloud)	Local, signatures limitées
Limitation de connexion	Oui (intégré)	Oui (via WAF cloud)	Oui (intégré)
Double authentification	Oui (TOTP)	Non (plugin tiers)	Oui (TOTP, pro)
Impact CPU au scan	Élevé	Faible (distant)	Modéré
Prix version pro (par an)	À partir de 149 $	À partir de 199 $/an	À partir de 69,99 €
Nombre d’installations actives	5 millions+	900 000+	40 000+

D’autres extensions méritent d’être mentionnées. Solid Security (anciennement iThemes Security) propose un assistant de configuration par profil de site. All-In-One WP Security reste populaire pour sa gratuité totale et son système de score par points. Le choix final dépend du profil du site, détaillé plus bas.

Voir aussi Attaques par force brute sur la page de connexion : les bloquer efficacement

Entre 2 et 12 requêtes SQL par page : le coût réel sur les performances

Chaque plugin de sécurité enregistre des données dans la base de données WordPress : journaux de connexion, adresses IP bloquées, résultats de scan, règles de pare-feu. Ce stockage génère des requêtes SQL supplémentaires à chaque chargement de page, même pour un visiteur non connecté.

Des tests réalisés avec Query Monitor sur un site de 50 pages montrent les résultats suivants. Wordfence ajoute en moyenne 6 à 12 requêtes SQL par page chargée. SecuPress en ajoute 2 à 5. All-In-One WP Security se situe entre 3 et 7. Sucuri, lorsque le pare-feu est en mode cloud, n’ajoute que 1 à 3 requêtes côté serveur, le filtrage étant déporté.

Sur un hébergement mutualisé avec des ressources limitées, ces requêtes supplémentaires se traduisent par un allongement du temps de génération de la page compris entre 20 et 80 ms. Sur un serveur dédié ou un VPS bien dimensionné, l’impact reste négligeable. La qualité de l’hébergement est donc déterminante, comme l’explique l’article sur les causes réelles d’un site lent.

Le problème s’aggrave avec le temps. Les tables de journalisation (wp_wfHits, wp_wfLogins pour Wordfence par exemple) grossissent sans limite si la purge automatique n’est pas configurée. Au bout de six mois, ces tables peuvent atteindre plusieurs centaines de mégaoctets, ralentissant toutes les opérations de la base. Le nettoyage régulier est abordé dans le guide sur la maintenance de la base de données WordPress.

Pare-feu côté serveur ou côté cloud : l’impact mesuré sur le TTFB

Le Time To First Byte (TTFB) mesure le délai entre la requête du navigateur et la réception du premier octet de réponse. Un pare-feu applicatif intervient avant la génération de la page : son impact sur le TTFB est donc direct et mesurable.

Un pare-feu côté serveur (Wordfence, SecuPress) analyse chaque requête HTTP dans le processus PHP. Sur un mutualisé OVH ou o2switch, les mesures publiées par plusieurs benchmarks indépendants montrent un surcoût de 40 à 120 ms sur le TTFB lorsque le WAF est actif, par rapport au même site sans extension de sécurité. Sur un VPS avec 4 Go de RAM et un cache opcode (OPcache), ce surcoût tombe à 10 à 30 ms.

Un pare-feu cloud (Sucuri, Cloudflare WAF) ajoute un saut réseau. La requête du visiteur atteint d’abord le point de présence (PoP) du fournisseur, qui la filtre, puis la transmet au serveur d’origine. La latence ajoutée dépend de la distance géographique entre le PoP et le serveur. Pour un site hébergé en France avec des visiteurs français, le surcoût mesuré est de 5 à 25 ms si le PoP est en Europe de l’Ouest. En revanche, le serveur d’origine est déchargé du filtrage, ce qui compense souvent le saut réseau. Le fonctionnement d’un réseau de distribution de contenu est expliqué dans l’article sur ce que change réellement un CDN sur un site français.

Le score PageSpeed Insights peut être affecté par ces variations de TTFB. Sur un site dont le TTFB initial est déjà au-dessus de 600 ms, l’ajout d’un WAF côté serveur risque de faire basculer le score dans le rouge. Sur un site rapide (TTFB sous 200 ms), l’impact reste imperceptible pour l’utilisateur.

Quatre protections que l’on peut activer sans extension

Certaines fonctions proposées par les plugins de sécurité peuvent être assurées directement par la configuration du serveur ou du fichier .htaccess, sans charger de code PHP supplémentaire. Cette approche élimine l’impact sur les performances tout en maintenant la protection.

1. Bloquer l’accès à xmlrpc.php. Ce fichier, utilisé historiquement pour les publications à distance, est aujourd’hui le vecteur principal d’attaques par amplification. Une simple règle dans le fichier .htaccess suffit à le désactiver :

<Files xmlrpc.php>
Order Deny,Allow
Deny from all
</Files>

2. Masquer la version de WordPress. L’affichage du numéro de version dans le code source facilite le ciblage d’exploits connus. Une ligne dans le fichier functions.php du thème enfant supprime cette information : remove_action('wp_head', 'wp_generator');

3. Forcer les en-têtes de sécurité HTTP. Les en-têtes X-Content-Type-Options, X-Frame-Options et Content-Security-Policy peuvent être ajoutés via la configuration Apache ou Nginx. Selon les recommandations de l’ANSSI (Agence nationale de la sécurité des systèmes d’information), ces en-têtes constituent une couche de défense indispensable.

4. Restreindre l’accès à wp-admin par adresse IP. Pour les sites administrés depuis un nombre limité de postes, une règle .htaccess dans le dossier wp-admin peut limiter l’accès aux seules adresses IP autorisées. Cette mesure est plus efficace qu’une limitation par tentative de connexion, car la requête est rejetée avant même de toucher PHP.

Ces quatre mesures ne remplacent pas un scan de malware ni une surveillance en temps réel, mais elles allègent considérablement la charge que le plugin doit gérer. Le certificat SSL, autre composant de sécurité, relève d’une configuration distincte abordée dans l’article sur le choix entre certificat SSL gratuit ou payant.

Quel plugin choisir selon le profil et l’hébergement du site

Le meilleur plugin de sécurité WordPress n’est pas celui qui offre le plus de fonctions, mais celui dont l’architecture correspond aux contraintes du site. Voici les recommandations selon trois profils courants.

Site vitrine sur hébergement mutualisé (moins de 500 visites par jour). Le CPU et la mémoire sont partagés avec d’autres sites. Un plugin gourmand en scans provoquera des ralentissements visibles. SecuPress en version gratuite ou All-In-One WP Security sont les options les plus légères. Le scan de fichiers doit être programmé en heures creuses (entre 3 h et 5 h du matin). La bande passante disponible sur ce type d’offre est détaillée dans l’article sur l’espace disque et la bande passante nécessaires.

Site e-commerce ou site à fort trafic sur VPS ou serveur dédié. Les ressources sont suffisantes pour un WAF côté serveur. Wordfence Premium est le choix le plus complet : ses règles de pare-feu en temps réel, sa base de signatures mise à jour toutes les heures et son scan approfondi exploitent pleinement un serveur bien dimensionné. L’alternative est Sucuri avec pare-feu cloud, qui décharge le serveur pour laisser toutes les ressources au traitement des commandes.

Réseau multisite ou agence gérant plusieurs sites. La gestion centralisée devient le critère principal. Wordfence Central permet de superviser tous les sites depuis un tableau de bord unique. SecuPress Pro offre une licence multisites à prix fixe (69,99 € pour un nombre illimité de sites). Le versionnement des configurations de sécurité peut s’appuyer sur Git pour versionner le site.

Configuration minimale pour protéger sans alourdir le site

Quelle que soit l’extension choisie, une configuration raisonnée permet de conserver 90 % de la protection tout en réduisant l’impact sur les performances de 60 %. Les réglages suivants s’appliquent à la plupart des plugins du marché.

Désactiver le trafic en direct (Live Traffic). Cette fonction, activée par défaut dans Wordfence, enregistre chaque requête HTTP dans la base de données. Sur un site recevant 1 000 visites par jour, cela représente plusieurs milliers d’écritures SQL quotidiennes. La désactiver réduit immédiatement la charge sur la base. Les alertes de sécurité restent fonctionnelles sans cette option.

Programmer les scans en heures creuses. Un scan d’intégrité des fichiers peut consommer entre 50 et 80 % du CPU pendant 2 à 15 minutes selon la taille du site. Programmer ce scan entre 2 h et 5 h du matin évite tout impact sur l’expérience des visiteurs. Un scan quotidien est suffisant pour un site vitrine ; un site e-commerce peut justifier deux scans par jour.

Limiter la rétention des journaux. Configurer la purge automatique des logs à 30 jours maximum. Au-delà, les tables de journalisation grossissent inutilement. Wordfence propose ce réglage dans « All Options > General Wordfence Options > Delete Wordfence tables ». SecuPress purge automatiquement les anciens logs.

Activer le cache de pages en complément. Un plugin de cache (WP Super Cache, WP Rocket, W3 Total Cache) sert les pages statiques aux visiteurs non connectés, contournant ainsi le surcoût du WAF pour la majorité du trafic. La distinction entre les différents niveaux de cache est expliquée dans l’article sur le cache navigateur, serveur et CDN.

Maintenir PHP à jour. Les performances du WAF dépendent directement de la version de PHP. Le passage de PHP 7.4 à PHP 8.2 réduit le temps d’exécution des règles de pare-feu d’environ 25 à 35 % selon les benchmarks publiés par php.net. La procédure est décrite dans le guide sur la mise à jour de la version de PHP.

Les cinq erreurs qui transforment un plugin de sécurité en problème

Un plugin de sécurité mal configuré cause parfois plus de dégâts qu’une absence de protection. Voici les cinq erreurs les plus fréquentes, identifiées dans les forums de support et les rapports d’incidents.

Empiler plusieurs plugins de sécurité. Installer Wordfence et Sucuri simultanément ne double pas la protection : les deux pare-feu entrent en conflit, génèrent des faux positifs et peuvent tripler le nombre de requêtes SQL par page. Un seul plugin de sécurité complet suffit.

Ignorer les mises à jour du plugin lui-même. Un plugin de sécurité obsolète contient potentiellement des vulnérabilités connues. Selon le référentiel CVE, plusieurs failles critiques ont été découvertes dans des extensions de sécurité populaires ces dernières années. Les mises à jour automatiques sont abordées dans l’article sur les mises à jour WordPress à activer sans risque.

Activer toutes les options sans comprendre leur effet. Le blocage de pays entiers, le changement de l’URL de connexion, ou la désactivation de l’API REST peuvent casser des fonctionnalités légitimes. L’API REST, par exemple, est utilisée par l’éditeur Gutenberg et par de nombreux plugins, comme l’explique l’article sur le rôle concret de l’API REST.

Ne pas tester la sauvegarde après installation. Un pare-feu trop strict peut empêcher le fonctionnement d’un plugin de sauvegarde. Il est indispensable de vérifier que le processus de sauvegarde et de restauration reste opérationnel après l’activation du plugin de sécurité.

Négliger la surveillance après le déploiement. Installer un plugin de sécurité et ne jamais consulter ses alertes revient à installer une alarme sans la brancher. Un minimum de vérification hebdomadaire du tableau de bord est nécessaire pour s’assurer que le plugin fonctionne correctement et que les mises à jour de signatures sont bien appliquées.

À retenir

Choisir un seul plugin de sécurité adapté au type d’hébergement du site
Programmer les scans de fichiers entre 2 h et 5 h du matin pour éviter l’impact sur les visiteurs
Désactiver le suivi du trafic en direct et limiter la rétention des logs à 30 jours
Configurer les en-têtes de sécurité HTTP et le blocage de xmlrpc.php directement côté serveur
Vérifier que le processus de sauvegarde fonctionne après chaque modification des règles du pare-feu

Questions fréquentes

Un plugin de sécurité gratuit suffit-il pour un site vitrine ?

Pour un site vitrine recevant moins de 500 visites quotidiennes, la version gratuite de Wordfence ou de SecuPress couvre les besoins essentiels : pare-feu basique, limitation des tentatives de connexion et scan d’intégrité. Les versions payantes ajoutent des règles de pare-feu en temps réel et un support prioritaire, utiles surtout pour les sites e-commerce ou à fort trafic.

Wordfence ralentit-il vraiment le site ?

Wordfence ajoute entre 6 et 12 requêtes SQL par page et son scan de fichiers peut consommer jusqu’à 80 % du CPU sur un hébergement mutualisé. Sur un VPS ou un serveur dédié correctement dimensionné, l’impact est négligeable. La désactivation du suivi en direct du trafic et la programmation des scans en heures creuses réduisent significativement la charge.

Peut-on utiliser deux plugins de sécurité en même temps ?

Non. L’utilisation simultanée de deux pare-feu applicatifs provoque des conflits de règles, des faux positifs et une multiplication des requêtes SQL. Il est recommandé de choisir un seul plugin complet et de compléter avec des mesures côté serveur (en-têtes HTTP, blocage de xmlrpc.php) plutôt que d’empiler les extensions.

SecuPress est-il une alternative fiable à Wordfence ?

SecuPress est une alternative crédible, particulièrement pour les sites hébergés sur des mutualisés où les ressources sont limitées. Son empreinte mémoire est plus légère et son interface simplifiée convient aux utilisateurs non techniques. En revanche, sa base de signatures de malware est moins étendue que celle de Wordfence et sa communauté d’utilisateurs est plus restreinte (40 000 installations contre 5 millions).

Un pare-feu cloud comme Sucuri est-il plus efficace qu’un pare-feu local ?

Un pare-feu cloud filtre le trafic avant qu’il n’atteigne le serveur, ce qui décharge complètement les ressources du site. C’est un avantage net pour les hébergements modestes. En revanche, il ajoute un saut réseau (5 à 25 ms de latence) et nécessite une modification des enregistrements DNS. Un pare-feu local offre un contrôle plus granulaire mais consomme les ressources du serveur.

Comment savoir si mon plugin de sécurité consomme trop de ressources ?

L’extension Query Monitor, gratuite, affiche le nombre de requêtes SQL, le temps de génération de la page et la consommation mémoire pour chaque chargement. Si le plugin de sécurité ajoute plus de 8 requêtes SQL ou si le temps de génération dépasse 500 ms, il est pertinent de revoir la configuration ou de changer d’extension.

Damien Roux

Damien Roux est spécialiste de l'hébergement web. Fondateur de web-city.fr, il partage guides pratiques, comparatifs objectifs et outils gratuits pour choisir le bon hébergeur et créer son site WordPress.