Un blog WordPress se sécurise avant l'incident, jamais pendant. L'écart entre une alerte traitée en vingt minutes et trois jours de site hors ligne tient à des décisions prises des mois plus tôt : les extensions installées, les comptes laissés ouverts, la dernière sauvegarde que quelqu'un a réellement restaurée.
J'accompagne des TPE et des PME sur WordPress depuis 2012, et les installations qu'on me confie en urgence se ressemblent beaucoup : une trentaine d'extensions dont la moitié ne sert plus, plusieurs comptes administrateur dont certains appartiennent à d'anciens prestataires, une sauvegarde quotidienne que personne n'a jamais testée. Cet article décrit les mesures de prévention qui réduisent vraiment le risque, et celles qui donnent seulement l'impression de le réduire. Si le mal est déjà fait, la marche à suivre est différente : elle fait l'objet d'un article distinct sur la procédure après un piratage.
Le risque ne vient presque jamais du cœur de WordPress
WordPress fait tourner 40,3 % de l'ensemble des sites web et 58,8 % de ceux dont le CMS est identifié, d'après les relevés W3Techs arrêtés au 11 septembre 2026 (mesure automatisée sur le top 10 millions de sites). Cette part de marché explique le volume d'attaques, pas leur cause.
Le rapport State of WordPress Security de Patchstack publié le 25 février 2026 recense 11 334 nouvelles vulnérabilités dans l'écosystème WordPress sur l'année 2025, soit 42 % de plus qu'en 2024. La répartition est sans ambiguïté : 91 % concernent des extensions, 9 % des thèmes, et 6 vulnérabilités seulement touchent le cœur, toutes classées en priorité basse. Votre surface d'attaque, c'est ce que vous avez ajouté.
Deux autres chiffres du même rapport comptent : 46 % des vulnérabilités n'avaient reçu aucun correctif au moment de leur divulgation publique, et 29 % des signalements portent sur des composants premium ou freemium. Payer une extension ne garantit rien.
Mettre à jour : ce qui doit être automatique, ce qui ne doit pas l'être
La branche courante est WordPress 7.1, sortie le 19 août 2026 d'après le registre officiel des versions. Depuis WordPress 5.6, les nouvelles installations reçoivent automatiquement les mises à jour mineures et majeures du cœur ; les plus anciennes ne reçoivent par défaut que les mineures et les traductions, comme l'explique la documentation officielle. Extensions et thèmes ne sont mis à jour d'office que dans des cas exceptionnels décidés par l'API WordPress.org.
Ma règle de travail est simple. Automatique pour le cœur en version mineure et pour les extensions à faible risque de régression (sécurité, SEO technique, sauvegarde). Manuel, après test sur une préproduction, pour tout ce qui touche l'affichage ou les paiements : constructeur de pages, thème, module e-commerce, passerelle bancaire. Et une fenêtre hebdomadaire de vingt minutes pour le reliquat : un site qu'on met à jour « quand on y pense » est un site qu'on ne met pas à jour.
Réduire la surface : choisir et élaguer les extensions
Chaque extension est du code tiers exécuté avec les droits de votre site. Avant d'installer, je regarde quatre choses : date de dernière mise à jour, nombre d'installations actives, réactivité de l'éditeur sur le forum de support, compatibilité déclarée avec la version courante de WordPress. Une extension sans mise à jour depuis douze mois est un passif, quel que soit son nombre d'étoiles.
L'élagage compte autant que le choix. Une extension désactivée reste présente sur le disque et reste exploitable : désactiver n'est pas désinstaller. Une revue annuelle suffit pour supprimer ce qui ne sert plus et remplacer ce qui n'est plus maintenu. Sur les sites que je reprends, c'est l'opération qui fait le plus baisser le risque, avant tout outil de sécurité.
Comptes, rôles et authentification
Le principe de moindre privilège s'applique littéralement : un rédacteur n'a pas besoin du rôle Administrateur, un prestataire ponctuel non plus. Limitez le nombre d'administrateurs à ce que vous pouvez nommer de mémoire, et supprimez les comptes des prestataires en fin de mission plutôt que de les désactiver. Le rapport d'activité 2025 de Cybermalveillance.gouv.fr, publié le 26 mars 2026, place le piratage de compte en tête des menaces signalées par les professionnels, en hausse de 45 % sur un an — le compte, pas la faille logicielle.
Mots de passe et double authentification
La recommandation de la CNIL sur les mots de passe (délibération du 21 juillet 2022, publiée le 14 octobre 2022) raisonne en entropie plutôt qu'en composition imposée : 80 bits sans mesure complémentaire, 50 bits lorsque des restrictions d'accès existent (blocage après plusieurs échecs, temporisation). Elle a abandonné le changement périodique obligatoire pour les utilisateurs courants, tout en le maintenant pour les comptes à privilèges. Concrètement : un gestionnaire de mots de passe, des secrets uniques par site, et pas de rotation mensuelle rituelle qui finit sur un post-it.
La double authentification reste la mesure au meilleur rapport effort/effet. WordPress ne l'inclut pas dans son cœur, mais l'extension Two Factor, maintenue par la communauté WordPress.org (plus de 100 000 installations actives), couvre les codes TOTP d'une application d'authentification, les codes de secours et l'envoi par e-mail, avec un module complémentaire pour les clés de sécurité WebAuthn. Activez-la au moins sur tous les comptes administrateur.
Mots de passe d'application
Depuis WordPress 5.6, les mots de passe d'application authentifient un outil externe sur l'API REST sans lui confier le mot de passe du compte, comme le décrit la documentation de l'API REST. Chaque clé est nommée, révocable individuellement et transmise en HTTPS : quand un prestataire part ou qu'un outil est abandonné, vous révoquez la sienne sans toucher au reste.
Une sauvegarde non testée n'est pas une sauvegarde
Les bonnes pratiques publiées par Cybermalveillance.gouv.fr sur les sauvegardes (page mise à jour le 24 février 2026) tiennent en trois idées : plusieurs copies sur des supports différents, au moins une copie déconnectée ou hors site, et une vérification régulière que la restauration fonctionne réellement.
Pour un site WordPress : une sauvegarde qui embarque la base de données et les fichiers, stockée ailleurs que sur le serveur du site, avec une rétention suffisante pour couvrir une compromission découverte tardivement. Trente jours est un minimum raisonnable, car une porte dérobée installée il y a six jours se retrouve dans toutes les sauvegardes des six derniers jours. Et une fois par trimestre, restaurez pour de vrai sur un environnement de test, chronomètre en main : c'est le seul moyen de connaître votre délai de remise en ligne avant d'en avoir besoin.
Hébergement, version de PHP et journalisation
WordPress 7.1 fonctionne à partir de PHP 7.4, mais c'est un plancher de compatibilité, pas une cible. D'après le calendrier officiel de support de PHP, PHP 8.2 ne reçoit plus que des correctifs de sécurité jusqu'au 31 décembre 2026, PHP 8.3 jusqu'à fin 2027, PHP 8.4 jusqu'à fin 2028 et PHP 8.5 jusqu'à fin 2029. Rester sur une branche en fin de vie, c'est accumuler des failles que personne ne corrigera. Vérifiez votre version dans Outils puis Santé du site.
Côté hébergement, les critères qui comptent sont prosaïques : isolation des sites entre eux, accès SSH ou SFTP plutôt que FTP en clair, certificat TLS renouvelé automatiquement, préproduction en un clic, conservation des journaux. Journaux d'accès, connexions à l'administration, modifications de fichiers : sans eux, l'analyse d'un incident se fait à l'aveugle. Trente à quatre-vingt-dix jours de rétention suffisent le plus souvent. Ces exigences se négocient au choix de la plateforme, donc dès la création du site.
Le pare-feu applicatif : utile, à sa juste place
Un pare-feu applicatif (WAF), installé comme extension ou placé en amont au niveau du DNS, filtre les requêtes avant qu'elles n'atteignent PHP. Son intérêt tient au chiffre cité plus haut : avec 46 % des vulnérabilités divulguées sans correctif disponible, il existe des fenêtres pendant lesquelles vous ne pouvez pas mettre à jour. Les règles de correction virtuelle bloquent l'exploitation connue en attendant le patch de l'éditeur.
Il ne remplace ni les mises à jour, ni l'élagage des extensions, ni la double authentification. Posé sur une installation avec douze extensions abandonnées et quatre comptes administrateur orphelins, il ne fait que déplacer le problème.
Ce qui ne sert (presque) à rien
Certaines recettes circulent depuis quinze ans et survivent surtout parce qu'elles sont faciles à appliquer. Masquer le numéro de version de WordPress dans le code source : un scanner la déduit des ressources chargées en quelques secondes. Supprimer readme.html : même chose. Renommer wp-content : casse régulièrement des extensions pour un gain nul.
Le cas de wp-login.php est plus nuancé. Déplacer la page de connexion réduit le bruit des robots dans vos journaux, ce qui est un confort réel, mais ne protège d'aucune vulnérabilité d'extension et casse parfois les intégrations qui s'attendent à l'URL standard. La documentation officielle de durcissement de WordPress le formule bien : la sécurité par l'obscurité est une stratégie principale peu solide. Elle peut compléter le reste, jamais le remplacer. À l'inverse, une mesure discrète et vraiment efficace consiste à ajouter define( 'DISALLOW_FILE_EDIT', true ); dans wp-config.php : l'éditeur de fichiers du tableau de bord disparaît, et avec lui l'outil le plus commode dont dispose un attaquant ayant obtenu un compte administrateur.
La routine qui tient dans un agenda
| Fréquence | Action | Signal qui doit alerter |
|---|---|---|
| Hebdomadaire | Appliquer les mises à jour non automatisées, parcourir le journal des connexions administrateur | Une connexion admin hors horaires ou depuis un pays inattendu |
| Mensuelle | Revue des comptes et des rôles, révocation des mots de passe d'application inutilisés | Un compte administrateur que personne ne revendique |
| Trimestrielle | Restauration réelle d'une sauvegarde sur un environnement de test | Une restauration plus longue que le délai que vous vous êtes fixé |
| Annuelle | Élagage des extensions, vérification de la version de PHP et des engagements de l'hébergeur | Une extension sans mise à jour depuis plus de douze mois |
Ces quatre lignes coûtent moins d'une heure par mois, peu au regard du temps qu'exige une remise en état. C'est aussi le moment où la dette technique apparaît : si l'inventaire révèle un thème abandonné, un constructeur de pages obsolète et PHP 7.4, le sujet n'est plus la sécurité seule mais une refonte WordPress à planifier avant d'y être contraint.
Questions fréquentes
Faut-il activer les mises à jour automatiques des extensions WordPress ?
Oui pour les extensions à faible risque de régression visuelle ou fonctionnelle, comme les outils de sécurité, de sauvegarde ou de SEO technique. Pour un constructeur de pages, un thème ou un module de paiement, il vaut mieux tester la mise à jour sur un environnement de préproduction avant de l'appliquer. Dans les deux cas, prévoyez un créneau hebdomadaire pour traiter ce qui n'a pas été automatisé.
Combien d'extensions peut-on installer sans prendre de risque ?
Il n'existe pas de seuil chiffré : ce qui compte est la qualité de maintenance de chaque extension, pas leur nombre brut. Le rapport Patchstack publié en février 2026 attribue 91 % des vulnérabilités de l'écosystème WordPress en 2025 à des extensions, ce qui justifie de supprimer tout ce qui ne sert plus. Retenez qu'une extension désactivée reste présente sur le serveur et doit être désinstallée, pas simplement éteinte.
La double authentification est-elle incluse dans WordPress ?
Non, le cœur de WordPress ne propose pas nativement de second facteur d'authentification. Il faut passer par une extension, par exemple Two Factor, maintenue par la communauté WordPress.org, qui gère les codes TOTP, les codes de secours et l'e-mail. L'activer au moins sur les comptes administrateur est l'une des mesures les plus efficaces au regard de l'effort demandé.
Un pare-feu applicatif remplace-t-il les mises à jour ?
Non. Un pare-feu applicatif sert surtout à couvrir la période pendant laquelle une vulnérabilité est connue mais pas encore corrigée par l'éditeur de l'extension, grâce à des règles de correction virtuelle. Il ne dispense ni d'appliquer les correctifs, ni de réduire le nombre d'extensions installées, ni de sécuriser les comptes.
Déplacer la page de connexion wp-login.php améliore-t-il la sécurité ?
Marginalement. Cela réduit le bruit des robots dans les journaux et allège un peu la charge du serveur, mais ne protège contre aucune vulnérabilité d'extension ou de thème. Cette mesure peut aussi casser des intégrations qui s'attendent à l'URL standard, elle ne doit donc jamais être considérée comme une protection principale.
À quelle fréquence faut-il tester ses sauvegardes ?
Un test de restauration complet par trimestre constitue un rythme raisonnable pour un site de TPE ou de PME. L'objectif est double : vérifier que l'archive est exploitable et mesurer le délai réel de remise en ligne. Conservez par ailleurs au moins trente jours d'historique, car une compromission est souvent découverte plusieurs jours après son installation.