10 raisons de ne pas utiliser Wordpress

Selon le classement quotidien du 3 octobre 2022 réalisé par l’institut W3Techs, Wordpress serait toujours le leader sur le marché des sites internet. Dans le détail, 33% des sites internet n’utilisent aucun des systèmes de gestion de contenu (CMS) contre 67% de sites internet qui en utilisent un. Ce qui fait que Wordpress totalise 43% des parts de marché tout type de sites confondu et 64,3% des sites utilisant un système de gestion de contenu (CMS). C’est la raison pour laquelle les sites sous Wordpress sont spécialement privilégiés par les pirates.

Dès la découverte d’une faille de sécurité, on devine déjà les répercussions désastreuses que cela va produire. Malgré l’arrivée rapide d’un patch de correction pour combler la faille, il est souvent déjà trop tard. Beaucoup de pirates ont déjà rapidement profité de la faille sur l’ensemble des sites internet construits sous Wordpress.

De plus, par manque de temps, de compétences, ou même d’information ; beaucoup de sites Wordpress ne sont pas mis à jour régulièrement et vont donc être piratés.

Voici pourquoi il est déconseillé de créer son site sous Wordpress.

Lorsqu’on installe des plugins ou des thèmes dans son site Wordpress, il est possible que des fichiers possèdent les mauvaises permissions d’accès en lecture et en écriture.

Par conséquent, si des personnes malveillantes repèrent qu’un fichier potentiellement important est accessible, les pirates vont être capable d’écrire un code malveillant dans un fichier en PHP qui sera une porte d’entrée.

En exécutant ce fichier qu’ils auront spécialement créé, les pirates vont pouvoir prendre le contrôle de votre serveur, espionner tout ce qui se passe sur votre site et prélever toutes les informations qui les intéressent ; sans se faire repérer. Certains bloquent même le site en exigeant une rançon pour le débloquer.

Exemple en novembre 2016, une faille critique a été découverte dans le plugin Revolution Image Slider. Il s’agissait d’une injection LFI (Local File Inclusion) qui permettait aux pirates de télécharger le fichier wp-config.

La solution est donc de faire très attention aux permissions de vos fichiers avec un réglage strict, ce qui me permet d’enchaîner avec le point n°2.

Depuis l’interface d’administration de Wordpress, nous avons la possibilité de lancer une mise à jour automatique, d’installer des extensions ou bien d’installer des thèmes.

Cependant, pour que cela fonctionne, l’utilisateur doit avoir les permissions en écriture sur les fichiers pour pouvoir les supprimer ou les mettre à jour.

Ce qui veut dire, qu’il y a toujours la possibilité en PHP de modifier les fichiers pour par exemple injecter du code malveillant.

Ce n’est donc pas une bonne chose.

La seule solution possible serait de mettre des permissions très restrictives permettant d’empêcher la possibilité d’écrire sur des fichiers. Pour mettre à jour son site Wordpress, installer des extensions ou des thèmes ; il faudra donc le faire en ligne de commande depuis son serveur.

Par défaut, Wordpress s’installe à la racine. C’est-à-dire que tous les fichiers contenant l’ensemble du site vont se retrouver à la racine web. Cette pratique est fortement déconseillée.

Il faudrait par exemple mettre tous les fichiers nécessaires au bon fonctionnement du site dans la racine puis dans un autre dossier que l’on peut nommer par exemple « Public », y ranger uniquement des fichiers que l'on a besoin. Cela permet d’éviter à quelqu’un connaissant la structure commune des sites Wordpress, qu’il puisse appeler des fichiers PHP qui ne seraient pas censés être accessibles.

Malheureusement pour des raisons de simplicité et particulièrement sur des hébergeurs mutualisés, Wordpress a choisi de tout mettre à la racine. Ce qui fait que si jamais on veut restreindre et modifier l’accès à des dossiers ou des fichiers, il y a de fortes chances d’en oublier. Ce qui représente un problème en termes de sécurité.

Même si notre site internet possède une structure d’organisation de fichiers un peu différente de l’original, on se retrouvera malgré tout avec ce problème de fichiers PHP accessibles.

Pour des raisons de compatibilité, Wordpress utilise par défaut un système de hachage basé sur la librairie PHP Pass.

La fonction de hachage est une fonction cryptographique capable de mapper une chaîne aléatoire (séquence de caractères) en une nouvelle chaîne de longueur prédéfinie.

Même si cette librairie est sécurisée, il utilise un chiffrement qui est relativement faible.

C’est la raison pour laquelle l’attaque par la méthode force brute fait partie des formes récurrentes de piratage de Wordpress les plus courantes. Le pirate utilise un logiciel pour tester différents mots de passe de manière automatique. Il faut savoir qu’un ordinateur personnel peut tester jusqu’à quelques millions de mots de passe par seconde.

Une attaque par force brute peut être totalement invisible, même s’il existe des moyens pour le voir dans le fichier de logs.

Ça va certes prendre un certain temps pour le pirate mais ça lui prendra un temps qui sera assez faible par rapport à d’autres librairies.

- Mot de passe de 6 lettres minuscules =  309 millions de combinaisons possibles.

- Mot de passe de 6 lettres mélangeant majuscules + minuscules = 2 milliards de combinaisons possibles.

- Mot de passe de 6 caractères mélangeant minuscules + majuscules + chiffres = 56 milliards de combinaisons possibles.

- Mot de passe de 6 caractères mélangeant minuscules + majuscules + chiffres + ponctuation = quasi impossible de pirater par force brute.

Pour stocker les données, Wordpress utilise une base de données qui est relativement générique. La particularité de cette base de données est qu’elle est structurée d’une façon faisant que lorsque Wordpress veut récupérer des informations, il fait beaucoup de requêtes SQL. C’est problématique.

Si on utilise le thème par défaut et que l’on souhaite lire un article, Wordpress opèrera entre 28 et 30 requêtes SQL environ. Mais il n’est pas rare que certains sites Wordpress, utilisant un thème différent du thème par défaut, exécutent plus d’une centaine de requêtes SQL. Cela met beaucoup trop de pression sur la base de données et fait ralentir l’affichage de la page.

La solution serait d’utiliser et de paramétrer des caches. Ceci implique de posséder beaucoup plus de connaissances pour mettre en place le bon système de cache en fonction de son site.

Il existe d'autres politiques particulières qui s’appliquent dans Wordpress, mais l'exemple le plus simple à expliquer concerne la sauvegarde des révisions.

Pour rappel, les révisions permettent de sauvegarder les modifications qui sont faites à votre article. C’est pratique parce que si vous avez commis une erreur, vous pouvez revenir en arrière.

Cependant, vous allez vous retrouver avec beaucoup trop d’informations stockées en base de données alors que ça ne sert pas forcément.

Wordpress ne sépare pas très bien les révisions des articles publiés. La table qui stocke les révisions avec vos articles va se remplir et s’alourdir alors que ça pourrait être stocké dans une autre table.

La solution serait donc de désactiver les révisions ou de réduire le nombre de révision qui sont sauvegardées pour vos articles.

Très souvent dans Wordpress, les utilisateurs installent des plugins pour étendre les fonctionnalités.

Malheureusement, ces plugins vont également enregistrer l’ajout de nouveaux CSS et de nouveaux Javascript. Donc si un site internet compte de nombreuses extensions, ou utilise un thème pas très bien conçu, il va cumuler encore et encore du code CSS et du code javascript. Lorsque l’on change de page, on peut donc avoir plus d’une vingtaine de fichiers javascript et CSS qui se chargent en même temps. C’est très mauvais en matière de performance.

Il faut donc faire attention si vous créez vos thèmes ou plugins et essayer de minimiser autant que possible ce chargement.

Il n’existe pas de moyen efficace pour y remédier sauf à coder soi-même. Même s’il existe des plugins pour réduire et optimiser tous les fichiers CSS et Javascript, l’effet secondaire c’est que cela peut créer d’autres problèmes de fonctionnement ou d’affichage. Ça peut aussi casser votre site et provoquer une erreur 500.

Par défaut, il existe quatre types d’images dans Wordpress : thumbnail, medium, large et original.

Mais lorsque l’on charge de nouvelles images, Wordpress va créer autant de formats d’image supplémentaires qu’il en sera détecté, en plus de celles qui existent par défaut.

C’est-à-dire que si on crée un thème ou s’il y a des plugins, et que l’on upload une image avec une taille différente de ce qui existe déjà dans Wordpress à un certain endroit ; cela ajoute un nouveau format d’image qui sera également utilisé pour toutes les autres images du site, même s’il n’y a pas d’utilité pour les autres images.

Par conséquent, si on a uniquement besoin d’un seul format d’image, on se retrouve à gérer un nouveau format pour toutes les autres images qui vont être chargées dans le site. Ce qui n’est pas très efficace.

De plus, si jamais vous possédez un site sur lequel vous changez le thème, vous allez posséder des formats d’image qui ne sont en finalité plus utilisés. Si votre espace disque est limité, ce n’est pas terrible.

Il n’existe pas de solution pour minimiser ce problème si ce n’est de faire attention lorsque l’on crée un thème et lorsque l’on ajoute des plugins en essayant de n’utiliser que les quatre formats d’image présent par défaut. Bon courage.

Oui vous ne rêvez pas et c’est un fait, Wordpress utilise bien du mauvais code. Ce code date d’anciennes versions PHP, faisant qu’aujourd’hui lorsque l’on trouve des thèmes, des plugins, ou même lorsque l’on essaye d’interagir avec le thème par défaut de Wordpress, on se retrouve avec de mauvaises pratiques et du code difficile à gérer.

Tout d’abord, pour étendre ses fonctionnalités, le système de Wordpress est basé sur des hooks et des filtres.

Les hooks sont des fonctions pouvant être appliquées à une action ou à un filtre dans WordPress. Les actions et les filtres sont des fonctions pouvant être modifiées par les développeurs de thèmes et de plugins afin de modifier une fonctionnalité WordPress par défaut.

Pour se greffer sur un filtre les méthodes PHP utilisée sont « add_filter » et « add_hook ». Je m’arrête là pour l’explication technique.

Malheureusement, il n’y a aucune visibilité sur l’ordre de ces hooks, ni comment ils sont déclarés.

Il n’est donc pas rare de récupérer un site Wordpress avec par exemple du contenu n’étant pas censé être là et ne pas savoir d’où il provient.

L’ajout de hooks n’importe où, sans aucune indication de l’endroit où ils ont été définis, ni dans quel ordre ils vont s’exécuter, complexifie le code.

Nous pouvons donc chercher partout dans le code, dans les plugins, dans les thèmes, ... pour essayer de comprendre lorsqu’il y a besoin d’intervenir. Cela demande donc non seulement pas mal de recherche et de temps mais cela nuit fortement au dépannage du site.

L'utilisation de variables globales est une mauvaise pratique. Concrètement, il n’est pas interdit d’utiliser les variables globales. En revanche, ce qui est fortement déconseillé, est de les utiliser à tort et à travers pour tout et n’importe quoi et c’est là que ça ne va plus.

Les variables globales WordPress sont des variables qui contiennent des informations générées par l'application. Ces variables globales sont accessibles pendant l'exécution de l'application et pendant le cycle de vie de la page.

Pourquoi est-ce déconseillé ?

1) L’opposé aux variables globales sont les variables locales. Les variables locales permettent de comprendre le code plus facilement mais également de le débuguer en cas de besoin.

2) L’utilisation de variables globales signifie qu’il n’y a pas de contrôles. N’importe quelle partie du code peut lire et modifier les variables globales sans tenir compte des contrôles fait par une partie du code.

3) L’utilisation de variables globales d’autres modules augmente la dépendance et la complexité du code.

4) L’utilisation de variables globales par plusieurs tâches d’exécution en parallèle, devient vite chaotique avec des résultats incohérents à cause d’interactions inattendues.

Exemple : Si je veux voir un article, Wordpress en arrière-plan va utiliser des variables globales pour récupérer l’article en question. Sans rentrer dans les détails, c’est par cette méthode que Wordpress sera capable d’aller chercher l’article que j’ai demandé. Cependant, à cause d’interactions pouvant être causé par un plugin ou un thème s’exécutant en parallèle, je n’obtiens pas l’article attendu car les variables globales utilisées à l’origine pour aller chercher mon article vont être modifiées par un plugin ou le thème car allez savoir pourquoi, ce plugin ou ce thème a besoin de modifier ces variables globales. Vu le nombre de plugins, encore faut-il trouver lequel est en train de nuire.

Comme pour les filtres et les hooks que l’on a vu précédemment, c’est un problème qui nuit à la visibilité du code et le complexifie.

Lorsque l'on maintient un site internet, cela mène très rapidement à des problèmes.

Si Wordpress est si mauvais d’un point de vue performance, sécurité et méthodologie, pourquoi est-il encore aujourd’hui très utilisé ?

C’est malheureusement un outil qui correspond à un besoin. L’utilisateur lambda veut simplement créer son site internet facilement et de manière autonome. L’utilisateur finit par ignorer si le code est bien écrit ou pas et s’il est sécurisé. De ce point de vue Wordpress remplit donc sa mission.

De plus, privilégiant son autonomie, l’utilisateur ne va pas réfléchir au fait qu’il y aura de grosses maintenances à faire, qu’il sera dans l’impossibilité de faire évoluer son site dans le temps par rapport à son activité à cause de la surcharge des plugins accumulés, et pour finir, tout le temps que cela va finir par prendre pour un résultat médiocre. Ce temps perdu, c’est du temps que l’utilisateur ne consacrera pas au développement de son entreprise.

Personnellement, je refuse de créer des sites sur Wordpress ou de reprendre le travail d’un autre fait sur ce CMS. C’est une perte de temps et d’argent pour tout le monde. De plus, il faut également savoir qu’un propriétaire d’un site créé sous Wordpress est juridiquement responsable en cas de fuite et vol de données, encore plus lorsqu’il est prouvé que le professionnel n’a pas mis tout en œuvre pour sécuriser les données qui étaient en sa possession. Le simple fait de l’utilisation de Wordpress comme site internet professionnel suffit amplement à démontrer que la sécurité n’était pas sa priorité car il est de notoriété publique que ce CMS est finalement une "passoire".

Tous les sites internet sont piratables et possèdent des failles, c’est une certitude. Mais Wordpress l’est plus que les autres. Je trouve personnellement qu’il est irresponsable pour un professionnel d’exploiter des données sensibles avec ce système de gestion de contenu.

Fort heureusement, il existe une alternative. Cette alternative s’appelle Joomla.

Avec Joomla vous travaillez rapidement et obtenez un site internet flexible, sécurisé avec un rendu très professionnel. La séparation du back-office (interface administrateur non visible par vos visiteurs) du front-office (la partie visible de votre site internet) garantit une gestion sécurisée de votre site. Il n'est pas nécessaire de charger beaucoup de plugins pour accroître les fonctionnalités de votre site web car Joomla possède énormément de fonctionnalités natives (contrairement à Wordpress). De plus, un site créé sous Joomla est évolutif à souhait. Vous ne perdrez pas votre temps et votre argent à repartir de zéro pour refondre totalement votre site.

Vous saurez tout de la petite histoire de ce grand CMS dans un prochain article.

La mauvaise réputation de Wordpress provient aussi de ses propres utilisateurs.

Par le fait qu’il soit simple à utiliser, beaucoup d'utilisateurs n'étant pas des développeurs très confirmés vont interagir dessus et cumuler les mauvaises expériences très rapidement.

Qu'ils se rassurent, les développeurs confirmés essayent eux aussi de travailler dessus mais avec beaucoup de mal à s’adapter à l’organisation du CMS.

L’effet pervers de Wordpress est que l’on se retrouve très vite avec beaucoup de plugins et de thèmes qui sont codés avec des méthodologies qui ne sont pas forcément cohérentes ; notamment pour certaines raisons que l’on a vues dans l'article ci-contre.

De plus, lorsque l’on essaye de maintenir un site Wordpress, c’est vite l’enfer car on met beaucoup trop de temps à comprendre comment les choses ont été faites, dans quel ordre et comment tout interagit ensemble.

Le temps c’est de l’argent, et plus un développeur passe du temps, et plus le client devra payer. Cela fini par coûter bien trop cher au client.

C'est la raison pour laquelle, les développeurs ne feront que les mises à jour de votre site et vous proposerons de le refondre si tel est votre besoin pour repartir quasiment de zéro. Mais ce sera encore la même chose lorsque votre activité évoluera encore et que votre site devra s'adapter à nouveau.