Checklist de durcissement de sécurité WordPress pour 2026

L'essentiel à retenir : le durcissement de WordPress n'est pas une correction unique mais une checklist en couches couvrant le contrôle d'accès, l'hygiène logicielle, la configuration au niveau serveur, les protections réseau et la surveillance continue — chaque couche ferme une catégorie de risque différente, et en sauter une laisse une brèche que les autres ne couvrent pas.

Pourquoi une checklist, pas une correction unique

Nous avons couvert les vulnérabilités spécifiques qui compromettent réellement les sites WordPress — plugins obsolètes, identifiants faibles, injection SQL, XSS, abus de XML-RPC — dans notre guide des vulnérabilités WordPress courantes. Le durcissement en est le pendant proactif : un ensemble structuré de choix de configuration qui réduit la surface d'attaque avant même qu'une vulnérabilité spécifique n'entre en jeu, organisé ici par couche pour que rien ne soit oublié.

Durcissement du contrôle d'accès

• Imposer l'authentification à deux facteurs pour chaque compte ayant un accès de publication ou d'administration, pas seulement l'administrateur principal.
• Appliquer des rôles à privilège minimal — donner à chaque utilisateur (et à chaque client, si le site est géré par une agence) le rôle WordPress le plus bas lui permettant d'accomplir son travail réel, plutôt que de faire de tout le monde un Administrateur par défaut.
• Supprimer immédiatement les comptes inutilisés quand un membre d'équipe ou une relation client se termine, plutôt que de laisser un compte dormant avec un accès permanent.
• Limiter les tentatives de connexion pour ralentir les outils de force brute automatisés ciblant wp-login.php.
• Renommer ou restreindre le nom d'utilisateur "admin" par défaut s'il est encore utilisé, puisque c'est le premier nom d'utilisateur que les attaques automatisées essaient.

Hygiène du cœur, des plugins et des thèmes

• Activer les mises à jour automatiques pour le cœur de WordPress, les plugins et les thèmes partout où la mise à jour comporte un faible risque de régression, et tester le reste sur une copie de staging avant de la pousser en production.
• Auditer les plugins installés chaque trimestre, en supprimant tout ce qui n'est pas activement utilisé — un plugin inactif avec une vulnérabilité connue reste exploitable dans certaines chaînes d'attaque même désactivé.
• Vérifier l'historique des vulnérabilités et l'activité de maintenance d'un plugin avant de l'installer, en privilégiant les plugins activement maintenus avec un historique de divulgation propre plutôt que les abandonnés.

Durcissement au niveau serveur et fichiers

• Régler les permissions de fichiers à 644 et de répertoires à 755, selon la propre documentation de durcissement de WordPress, avec wp-config.php idéalement encore plus verrouillé puisqu'il contient directement les identifiants de base de données.
• Désactiver l'édition de fichiers depuis wp-admin en ajoutant define('DISALLOW_FILE_EDIT', true); à wp-config.php, ce qui supprime l'éditeur de thème/plugin intégré donnant à un attaquant avec accès admin un chemin direct vers l'exécution de code.
• Désactiver la liste des répertoires sur le serveur pour qu'un dossier mal configuré n'expose pas une liste brute de fichiers à quiconque la demande directement.
• Changer le préfixe de table de base de données par défaut (wp_) lors de l'installation ou via un outil de migration, éliminant une hypothèse sur laquelle reposent certaines tentatives automatisées d'injection SQL.
• Désactiver XML-RPC sauf si un plugin spécifique (le plus souvent Jetpack) ou une application mobile le requiert activement.

Protections au niveau réseau

• Imposer HTTPS sur tout le site, en redirigeant tout le trafic HTTP, car une connexion non chiffrée expose les identifiants de connexion et les cookies de session à quiconque sur le même réseau.
• Ajouter un pare-feu applicatif web (WAF), via un service au niveau CDN ou un plugin de sécurité, pour bloquer les motifs d'attaque connus avant qu'ils n'atteignent WordPress lui-même.
• Définir des en-têtes de sécurité — Content-Security-Policy, X-Frame-Options et Strict-Transport-Security — que la plupart des CDN et certains plugins de sécurité peuvent appliquer sans toucher au propre code de WordPress.

Surveillance, journalisation et sauvegardes

• Activer la surveillance de l'intégrité des fichiers pour qu'un changement inattendu dans un fichier du cœur ou un fichier inconnu apparaissant dans wp-content déclenche une alerte plutôt que de passer inaperçu.
• Planifier des scans de malware réguliers, via un plugin de sécurité ou un service de scan externe, plutôt que de ne vérifier qu'une fois que quelque chose semble déjà anormal.
• Conserver des sauvegardes automatisées, hors site, selon un calendrier correspondant à la fréquence réelle des changements du site, et tester périodiquement qu'une sauvegarde se restaure réellement plutôt que de le supposer.
• S'abonner à un flux de divulgation de vulnérabilités comme WPScan ou Patchstack pour qu'une vulnérabilité de plugin nouvellement divulguée soit connue en quelques heures, pas découverte après exploitation.

Checklist complète en un coup d'œil

Le volet conformité : le durcissement n'est pas qu'un bonus sécuritaire

Pour les agences et entreprises opérant dans l'UE, les mesures de durcissement chevauchent de plus en plus des obligations réglementaires plutôt que d'être une simple bonne pratique optionnelle. Le Cyber Resilience Act de l'UE exige des fabricants de produits à éléments numériques — ce qui s'étend aux plugins et thèmes WordPress commerciaux sous certaines conditions — qu'ils respectent des exigences de cybersécurité de base et gèrent la divulgation des vulnérabilités de manière responsable tout au long de la vie d'un produit, pas seulement au lancement.

Les étapes de durcissement technique ci-dessus (mises à jour, contrôle d'accès, surveillance des vulnérabilités) soutiennent directement le volet sécurité de cette obligation, bien que la conformité complète nécessite aussi une documentation séparée — une politique de divulgation des vulnérabilités, une nomenclature logicielle (SBOM) et des registres de conformité — que le durcissement seul ne produit pas. C'est précisément la lacune que notre plugin Erdo CRA Compliance est conçu pour aider à combler : scanner un site selon les exigences CRA, RGPD et NIS2 et générer la documentation qu'une checklist de durcissement ne couvre pas à elle seule.

Erreurs courantes de durcissement

• Traiter le durcissement comme une tâche de configuration ponctuelle plutôt qu'une révision récurrente, laissant les comptes utilisateurs et les listes de plugins dériver hors d'un état sécurisé au fil des mois.
• Installer un plugin de sécurité et considérer la checklist terminée, alors que les permissions de fichiers au niveau serveur et les décisions de contrôle d'accès doivent toujours être traitées indépendamment.
• Durcir directement le site en ligne pour des changements comme désactiver l'édition de fichiers ou restreindre les permissions, sans tester d'abord sur staging au cas où un plugin dépendrait de la fonctionnalité désactivée.
• Ne jamais tester que les sauvegardes se restaurent réellement, découvrant une sauvegarde corrompue ou incomplète seulement pendant un incident réel.
• Appliquer toutes les étapes de durcissement sauf les mises à jour, alors que les logiciels obsolètes restent le point d'entrée le plus exploité, quel que soit le niveau de durcissement du reste.

En résumé

En bref, le durcissement de WordPress fonctionne comme une checklist en couches plutôt qu'une action unique — contrôle d'accès, hygiène logicielle, configuration serveur, protection réseau et surveillance continue ferment chacun une catégorie de risque différente, et pour les sites orientés UE, plusieurs de ces étapes servent désormais aussi de base pour la conformité réglementaire plutôt que d'être une simple bonne pratique optionnelle. Revoir la liste complète chaque trimestre, plutôt que de la mettre en place une fois et de supposer qu'elle tient, est ce qui maintient un site durci réellement durci à mesure que le temps passe.