Table des matières de l'article :
L'une des demandes les plus populaires des passionnés et des développeurs WordPress concerne la sécurité de leur installation et la possibilité de se défendre contre ces mystérieuses forces obscures appelées hackers.
La réponse est dans la plupart des cas donnée sur les groupes Facebook, les réseaux sociaux et les newsletters recommandant l'installation de plugins de sécurité tels que WordFence, Sucuri, iThemes Sécurité, très souvent même tous ensemble.
Ce qui n'est pas dit et ce que l'on ne sait surtout pas, c'est que ces plugins ont un impact important sur les performances, car pour chaque visite et pour différentes actions (comme la connexion) ces scripts (évidemment écrits dans un langage ne fonctionnant certainement pas comme PHP) vont pour effectuer toute une série d'opérations qui impactent la latence et la charge CPU.
Comment fonctionnent ces plugins de sécurité ? Voyons WordFence par exemple.
Directement sur leur site : https://www.wordfence.com/blog/2017/01/how-wordpress-firewall-works/ nous rapportons la version traduite en italien.
"Lorsque vous activez le pare-feu de Wordfence, nous utilisons une technique qui indique à votre serveur Web d'exécuter le code du pare-feu de Wordfence avant tout autre code PHP sur votre site Web. La façon dont nous procédons est d'inclure une directive dans votre fichier .htaccess appelée 'auto_prepend_file'. Cette directive renvoie au code Wordfence et garantit que Wordfence fonctionne avant toute autre chose.
Une fois que votre site Web est configuré pour lancer le pare-feu Wordfence, toute demande reçue, quel que soit le fichier PHP auquel il tente d'accéder, sera d'abord traitée par Wordfence pour vérifier si elle est sûre ou non. Notre pare-feu WordPress exécutera la demande via son propre ensemble de règles, effectuera une analyse détaillée de haute performance et prendra la décision de bloquer la demande ou de l'autoriser.
Le code du pare-feu qui exécute cette décision avant toute autre chose, y compris WordPress. Cela signifie que le code WordPress n'a pas été chargé et que la base de données n'est pas encore connectée. Cela rend le code du pare-feu de Wordfence incroyablement rapide . Nous pouvons bloquer une requête malveillante avant même qu'elle ne se connecte à votre base de données et avant que le code WordPress volumineux et l'environnement API ne soient chargés.
Le code du pare-feu de Wordfence s'exécute avant toute autre chose, y compris WordPress. Mais il a également la possibilité de transférer des données vers WordPress et d'obtenir des données de l'API WordPress. Cela nous permet d'intégrer l'identité de l'utilisateur dans notre ensemble de règles afin que nous puissions décider d'autoriser ou non l'accès d'un utilisateur, en fonction non seulement du contenu de la demande, mais aussi de qui il est et de son niveau d'accès. WordPress.
L'utilisation de ce modèle d'exécution haute performance signifie que les pirates n'atteignent que le pare-feu Wordfence superflu et ne peuvent pas le franchir. Les amis des visiteurs du site, les robots d'exploration et les utilisateurs peuvent accéder à votre site Web complet. Cela maintient votre site Web WordPress rapide et sécurisé. »
Haute performance ? Pour de vrai ?
Après tout, que signifie Haute Performance ? Par rapport à quoi ? Après tout, une Ferrari est rapide. Mais par rapport à qui ? A quoi ? Quels sont les critères de comparaison ?
Des performances élevées dans ce cas signifient que la manière adoptée pour travailler est la meilleure et la plus rapide pour un plugin WordPress qui doit s'occuper de fonctionner comme un WAF (Web Application Firewall), mais le fait que vous utilisez PHP (un logiciel vraiment lent et langue de blocage) pour effectuer i vérifier à CHAQUE VISITE fait de ce plugin une solution absolument pas idéale pour un blog ou un site WordPress à fort trafic.
Rappelez-vous toujours que PHP est un langage très lent.
Comme rapporté par de nombreux Benchmarks, PHP a une consommation CPU très élevée par rapport à d'autres langages tels que node.js à partir duquel nous avons rapporté le graphique ci-dessous. Cela a un fort impact sur les performances.
Pouvez-vous imaginer un site qui, pour chaque visite, doit effectuer ne serait-ce qu'une seule opération triviale en PHP ? Réalisez-vous ou non que le langage de programmation PHP est la chose la plus lente qui puisse exister ? Est-ce qu'on se rend compte que si on a 1000 visiteurs ou plus en ligne il est impensable d'activer PHP pour chaque visiteur pour éviter un ralentissement important des performances jusqu'à un plantage du système ?
Prenons par exemple cette capture d'écran d'il y a 5 jours. Un blog bien connu à fort trafic avec environ 15 250 utilisateurs connectés par minute, soit environ XNUMX utilisateurs par seconde. Serait-il vraiment logique d'exécuter un processus PHP pour chaque utilisateur ? Non. Évidemment.
Nos conseils
Le meilleur conseil que nous puissions donner concernant la sécurité de WordPress est de bien évaluer le choix d'installer ces plugins.
Si vous avez un site institutionnel qui est mis à jour rarement et n'a pas un pic important de visiteurs, vous pouvez également l'utiliser étant donné que cela mettra une plus grande charge sur la machine ainsi que sur la latence. Comme avantage vous aurez celui d'avoir le site un peu plus sécurisé.
Si par contre vous travaillez sur un site WordPress à fort trafic, le seul conseil valable que nous puissions vous donner est de ne pas installer ces plugins.
Si vous avez vraiment besoin d'une solution de sécurité qui se comporte comme un WAF (Web Application Firewall), utilisez des solutions côté systèmes (et non comme de simples plugins) telles que NAXI, ou le plus éprouvé mod_security. Si en revanche vous souhaitez utiliser des services externalisés, une version commerciale de CloudFlare à partir de 20€ par mois peut certainement être un bon point de départ pour obtenir un service WordPress Web Application Firewall sans alourdir le système et éviter les plantages.