WordPress et autres CMS : mises à jour, SSL, piratage

La sécurité d'un CMS désigne les protections qui empêchent un tiers de modifier un site web ou d'en voler les informations. CMS et sécurité se rejoignent d'abord dans la mise à jour du cœur, des thèmes et des extensions, puis dans HTTPS, des comptes bien gardés et des sauvegardes.

Pourquoi un CMS attire autant les attaques

Un CMS (content management system, ou logiciel de gestion de contenu) attire les attaques parce qu'il équipe des millions de sites web avec le même code. Une faille trouvée dans WordPress, Drupal ou une extension répandue s'exploite donc sur des milliers d'adresses à la fois, par des robots qui parcourent le web sans choisir leur cible. Le site d'une petite entreprise n'intéresse personne en particulier ; il intéresse tout le monde dès qu'il fait tourner une version vulnérable.

Les risques se rangent en quelques familles connues. L'injection SQL glisse une commande dans un champ de formulaire pour lire ou modifier les données. La faille XSS insère du JavaScript dans une page, qui s'exécute ensuite chez chaque visiteur. Le vol de mot de passe, par essais répétés sur la page de connexion ou par réutilisation d'un identifiant fuité ailleurs, donne la main sur l'administration. Le téléversement d'un fichier PHP déguisé en image ouvre une porte dérobée sur le serveur. S'ajoutent les thèmes « gratuits » récupérés hors des dépôts officiels, qui embarquent parfois du code caché dès l'installation.

Les extensions concentrent l'essentiel du danger. Les rapports annuels des éditeurs spécialisés dans la sécurité de WordPress, comme Patchstack ou Wordfence, attribuent la grande majorité des failles publiées aux extensions et aux thèmes, très loin devant le cœur du logiciel. Chaque module ajouté élargit la surface d'attaque : un site WordPress qui en compte trente dépend de trente auteurs différents, dont certains ne publient plus aucun correctif.

Un audit de cybersécurité mesure cette exposition avant qu'un attaquant ne s'en charge. Un expert, ou un outil de contrôle automatique, recense chaque vulnérabilité connue des modules installés, teste les formulaires contre l'injection et vérifie la configuration du serveur. Pour un blog personnel, un scanner gratuit et une liste de contrôle suffisent ; pour une boutique PrestaShop ou un site d'entreprise qui traite des données clients, un audit externe régulier fait partie de la conformité attendue par les partenaires et les assureurs en cybersécurité. La priorité reste la même partout : corriger d'abord ce qui est exposé sur internet.

Plusieurs guides gratuits servent de point de départ pour sécuriser un CMS. Le guide « Hardening WordPress » de la documentation officielle de wordpress.org détaille la protection des fichiers et des comptes ; Drupal publie son propre guide de sécurisation. Le guide d'hygiène informatique de l'ANSSI et le guide de la sécurité des données personnelles de la CNIL couvrent le reste de l'organisation, des sauvegardes à la gestion des accès. Le site cybermalveillance.gouv.fr propose enfin des ressources et une mise en relation avec des prestataires en cas de menace avérée.

CMS open source ou plateforme hébergée : quel modèle protège le mieux ?

Aucun CMS n'est sûr par nature : la sécurité d'un site tient surtout à la manière dont on l'administre. Un CMS open source publie son code source, ce qui permet à des milliers de développeurs de repérer les failles et aux attaquants de les étudier ; les correctifs sortent vite, à condition de les installer. Drupal dispose d'une équipe de sécurité qui publie des bulletins numérotés pour le cœur et les modules suivis, Joomla d'une équipe équivalente, et WordPress installe seul ses versions mineures depuis la 3.7.

Une plateforme hébergée (Wix, Shopify, Squarespace et leurs équivalents) prend la maintenance à sa charge : l'éditeur applique les correctifs sur l'ensemble de ses clients, sans action de leur part. En contrepartie, le code source reste fermé, l'export des données se révèle souvent limité et une faille chez l'éditeur touche tous les sites à la fois. Un générateur de pages statiques supprime enfin la base de données et l'interface d'administration publique : rien à injecter, rien à forcer, mais aucune mise en ligne sans compétences techniques.

Les solutions e-commerce suivent la même logique. PrestaShop, solution open source, laisse au marchand la charge des modules et des correctifs, alors qu'une offre hébergée sécurisée par l'éditeur s'en occupe grâce à une infrastructure commune. Le développement sur mesure, enfin, n'offre une plateforme sécurisée que si chaque évolution passe par une revue de code : l'expérience montre que les failles les plus durables naissent dans des fonctions développées pour un seul client, que personne d'autre ne relit. Chaque compte connecté à un service tiers (paiement, data analytique, outil marketing, plugin de cloud) ajoute aussi une clé d'accès à protéger.

Pour un débutant, la question de départ reste le budget de maintenance plus que le logiciel : les critères du CMS à choisir pour un premier site tiennent compte de ce suivi dans la durée.

Mettre à jour WordPress, Drupal et les extensions

La mise à jour du CMS forme la première protection d'un site, car les attaques visent surtout des failles déjà rendues publiques. WordPress publie des versions de maintenance à un rythme soutenu : la page des versions de wordpress.org mentionne la 7.1.3 et la 7.0.7, toutes deux sorties le 6 octobre 2026. Les mises à jour automatiques des versions mineures couvrent le cœur ; depuis la version 5.5, WordPress propose aussi d'activer l'installation automatique pour chaque extension et chaque thème, depuis leur écran de gestion.

Une extension abandonnée par son auteur, ou un vieux CMS dont l'éditeur ne publie plus rien, laisse des failles ouvertes pour de bon : la remplacer demande moins d'efforts qu'un nettoyage après intrusion. Supprimer les thèmes et modules désactivés va dans le même sens, car un fichier présent sur le serveur reste attaquable même désactivé dans l'administration.

Une mise à jour du cœur exige parfois un serveur plus récent. Selon la page des prérequis de wordpress.org, l'hébergement doit proposer PHP 8.3 ou plus récent, MySQL 8.0 ou plus récent, ou bien MariaDB 10.11 ou plus récent, ainsi que la prise en charge de HTTPS. Le changement de version de PHP se fait depuis le panneau de l'hébergement, selon les étapes de la rubrique PHP et serveurs. Sur un site d'entreprise qui vend en ligne, tester chaque mise à jour sur une copie (site de préproduction) avant de l'appliquer évite de casser une page de commande en pleine journée.

Un certificat SSL qui couvre www et le domaine nu

Le certificat SSL chiffre les échanges entre le navigateur et le site : le cadenas indique une connexion chiffrée par TLS avec un certificat valide pour le nom saisi. Un certificat émis pour exemple.fr seul déclenche une alerte sur www.exemple.fr : il doit lister les deux formes du nom de domaine, ou chaque forme doit avoir le sien. La barre verte d'autrefois, liée aux certificats à validation étendue, a disparu des navigateurs courants et n'ajoutait rien au chiffrement. L'extension SNI permet à un même serveur de présenter le bon certificat pour chacun des sites qu'il héberge.

L'en-tête HSTS demande au navigateur de ne plus revenir en HTTP ; il ne s'active qu'une fois toutes les adresses servies en HTTPS. Après le passage de WordPress en HTTPS, l'adresse du site et celle de WordPress passent toutes deux en https dans les réglages généraux. Les images restées en http dans les articles provoquent un avertissement de contenu mixte ; une recherche et remplacement dans les tables, après sauvegarde, les corrige. Sans HTTPS, un mot de passe saisi sur un réseau Wi-Fi public circule en clair : la sécurité de l'administration en dépend directement.

Comptes, mots de passe et droits d'accès

La sécurité des comptes compte autant que celle du code, puisqu'un identifiant volé ouvre l'administration sans exploiter la moindre faille. WordPress distingue cinq rôles (administrateur, éditeur, auteur, contributeur, abonné) : un rédacteur qui doit seulement publier du contenu n'a aucune raison de détenir un compte administrateur. Drupal et Joomla offrent des groupes et permissions plus fins encore. Pour les droits d'accès, chaque personne reçoit le rôle minimal pour son travail, et un compte inutilisé disparaît.

• Mot de passe unique et long par compte, stocké dans un gestionnaire, jamais partagé par courriel au sein de l'entreprise.
• Double authentification pour tous les comptes qui peuvent installer une extension ou modifier un thème, par une extension reconnue ou le module natif du CMS.
• Limitation des tentatives de connexion, pour ralentir les robots qui essaient des milliers de combinaisons.
• Éditeur de fichiers désactivé dans l'administration (constante DISALLOW_FILE_EDIT du fichier wp-config.php sous WordPress) : un pirate qui obtient un accès ne peut plus réécrire le code des thèmes en ligne.
• Accès FTP et SSH séparés des comptes du CMS, avec SFTP plutôt que FTP en clair.

Formulaires et code : bloquer injection SQL et faille XSS

Un formulaire mal protégé reste la porte d'entrée classique d'une injection : tout ce qu'un visiteur saisit doit se traiter comme une donnée suspecte. Les meilleures pratiques de sécurité pour un site internet tiennent en quelques gestes, que les extensions sérieuses appliquent déjà et que tout code sur mesure doit reprendre.

• Requêtes SQL préparées pour toute donnée venue d'un visiteur, jamais de concaténation directe dans la requête : la parade de base contre les injections de code malicieux dans les formulaires.
• Échappement à l'affichage, pour qu'un texte saisi ne devienne pas du code exécuté chez les autres visiteurs (la faille XSS).
• Jeton anti-falsification sur chaque formulaire, comme les nonces de WordPress, et limite aux envois répétés.
• Dossier temporaire et dossier d'envoi où PHP ne peut pas s'exécuter.
• En-têtes de sécurité envoyés par le serveur : Content-Security-Policy pour limiter les scripts autorisés, X-Content-Type-Options pour empêcher le navigateur de deviner le type d'un fichier.

La mise en œuvre de ces protections relève du développeur pour un thème ou une web application sur mesure ; sur un site WordPress standard, elle repose sur le choix d'extensions maintenues, dont le journal des versions montre des correctifs récents.

Hébergeur, entreprise, prestataire : qui protège quoi ?

La sécurité d'un CMS se partage entre plusieurs acteurs, et la plupart des sites piratés tombent dans l'espace que personne ne pensait couvrir. Sur un hébergement mutualisé, l'hébergeur protège le serveur, le système et souvent le pare-feu réseau ; il ne met pas à jour WordPress ni ses extensions à la place du client. Sur un VPS, la maintenance du système passe elle aussi au client : la différence entre un hébergement mutualisé ou un VPS se joue autant sur cette charge que sur la puissance.

Quand une agence a créé le site, le contrat dit si elle assure le suivi des mises à jour ou si sa mission s'arrête à la mise en ligne. Une entreprise qui n'a signé aucun contrat de maintenance porte seule cette tâche, souvent sans le savoir. Trois informations méritent une place écrite : qui détient les accès administrateur, où se trouvent les sauvegardes, et qui contacter le jour d'une intrusion (support client de l'hébergeur, agence, développeur indépendant).

Le droit ajoute une obligation. Un site qui stocke des données personnelles (comptes clients, formulaires de contact, commandes) relève du RGPD : son article 33 impose de notifier une violation de données à la CNIL dans les 72 heures après en avoir pris connaissance, lorsqu'elle présente un risque pour les personnes concernées. La notification se fait en ligne sur le site de la CNIL.

Détecter une intrusion et remettre le site en service

Une intrusion sur un CMS se repère rarement à l'écran d'accueil : le code ajouté cherche à rester discret. Les signes qui doivent alerter sont connus : redirections vers des pages inconnues sur mobile seulement, liens ou pages de pharmacie ajoutés à l'insu du propriétaire, comptes administrateurs inconnus, fichiers PHP récents dans le dossier des envois, alerte de Google Search Console ou du navigateur, hausse soudaine des courriels envoyés par le serveur. Une extension de surveillance qui compare les fichiers du cœur aux originaux, et l'examen des journaux de l'hébergement, confirment le diagnostic.

Le traitement suit un ordre précis. Mettre le site hors ligne ou en maintenance, pour protéger les visiteurs. Changer tous les mots de passe : administration, FTP, base de données, et les clés de sécurité du fichier de configuration. Restaurer une sauvegarde saine antérieure à l'intrusion, puis appliquer toutes les mises à jour avant de rouvrir, sinon la même faille sert une nouvelle fois. L'export et la restauration des tables sont abordés dans la rubrique bases de données SQL ; les droits des fichiers et l'accès FTP, dans la rubrique hébergement et services internet.

Une sauvegarde utile se stocke hors du serveur, chiffrée, avec une clé gardée ailleurs, et se teste : une copie jamais restaurée ne prouve rien. Un site lent du jour au lendemain peut aussi trahir un script malveillant qui consomme le processeur ; les causes d'un WordPress trop lent aident à écarter les pistes ordinaires.

Mise à jour qui casse le thème, extension de sécurité et Drupal

Un thème ou une extension peut-il casser la mise en page après une mise à jour ?

Une extension peut casser la mise en page quand elle remplace des styles du cœur ou d'une autre extension. Tester la mise à jour sur une copie du site, puis vider les caches, évite de découvrir le problème en production.

Une extension de sécurité suffit-elle à protéger un site WordPress ?

Une extension de sécurité ne suffit pas à protéger un site WordPress : elle filtre des attaques connues et signale des fichiers modifiés, mais elle ne remplace ni les mises à jour, ni des mots de passe solides, ni une sauvegarde externe.

WordPress est-il moins sûr que Drupal ?

WordPress n'est pas moins sûr que Drupal par construction : il est plus visé parce qu'il équipe bien plus de sites, et ses failles viennent surtout des extensions. Un WordPress tenu à jour avec peu d'extensions maintenues résiste mieux qu'un Drupal laissé sans correctifs.

Sources : page des versions de WordPress et prérequis d'hébergement de WordPress sur wordpress.org, consultées le 9 octobre 2026 ; article 33 du RGPD et page de notification des violations de données de la CNIL.