On sous-estime souvent le fait que WordPress n’est pas seulement un “site”. C’est une base de code, une base de données, un ensemble de plugins, un flux d’authentification, et une surface d’attaque qui s’agrandit à chaque ajout. J’ai vu des installations pourtant “à jour” tomber sur des détails simples: un thème abandonné, des identifiants réutilisés, une configuration d’hébergement trop permissive, ou des droits fichiers trop larges.
La bonne nouvelle, c’est que beaucoup de failles ne viennent pas d’exploits spectaculaires. Elles viennent d’habitudes: laisser l’inscription ouverte, exposer l’administration à Internet sans garde-fou, ne pas limiter les tentatives de connexion, accepter les mises à jour au hasard, ou laisser des fichiers temporaires et des traces accessibles.
Voici 25 réglages concrets pour renforcer la sécurisation WordPress, à activer dès aujourd’hui, avec l’esprit pratique d’un terrain réel.
1) Mettre WordPress et l’écosystème au même rythme
Premier levier: la fraîcheur. WordPress, le thème et les plugins doivent suivre le même rythme de maintenance. Si votre site a une politique “on met à jour quand ça va”, vous payez tôt ou tard cette hésitation, surtout quand un plugin critique prend une vulnérabilité.
Réglage n°1: planifier une mise à jour régulière, idéalement hebdomadaire pour les petits changements, et plus rapide quand la version corrige une sécurité.
Réglage n°2: vérifier avant déploiement que le plugin de sécurité, le cache et l’optimiseur (souvent liés) restent compatibles avec votre version PHP. Sur certains sites, une mise à jour a cassé la régénération du cache, et le correctif a ensuite créé un autre angle mort.Réglage n°3: supprimer les plugins inactifs et les thèmes non utilisés. Un plugin désactivé reste parfois présent dans le code, et il peut aussi porter des réglages de sécurité obsolètes. Sur un audit récent, une extension “déjà inactive” contenait un endpoint sensible accessible directement.
2) Passer à PHP 8.1 ou 8.2, et le garder stable
Beaucoup d’attaques opportunistes profitent de versions vieillissantes et d’effets de bord. Réglage n°4: utiliser une version PHP supportée, typiquement 8.1 ou 8.2 selon votre hébergement, et éviter les versions trop anciennes.
Réglage n°5: activer l’erreur minimale et surveiller les logs. WordPress n’a pas besoin d’erreurs verbeuses côté production, mais il a besoin de logs cohérents pour détecter un comportement suspect.Sur un site e-commerce, j’ai vu des erreurs PHP répétées provoquer un “glissement” du comportement des sessions. Ce n’est pas une attaque directe, mais c’est exactement le genre de fragilité qui se transforme en problème au pire moment.
3) Choisir des droits de fichiers et de dossiers raisonnables
Les permissions trop larges sont une porte. Les permissions trop strictes cassent la mise à jour. Il faut un équilibre.
Réglage n°6: vérifier que le répertoire d’installation et les dossiers critiques ont des droits cohérents avec votre serveur. En pratique, beaucoup d’installations utilisent 755 pour les dossiers et 644 pour les fichiers.
Réglage n°7: s’assurer que le serveur ne laisse pas l’exécution de scripts dans les répertoires qui ne devraient pas en exécuter (comme certains dossiers d’upload). Selon la stack, cela se gère dans la configuration serveur.Je recommande aussi de contrôler régulièrement la présence de fichiers “anormaux” dans le dossier racine, ou de nouveaux exécutables. Si votre hébergement le permet, une alerte d’intégrité fait gagner du temps.
4) Protéger le wp-admin et wp-login sans casser la vie
Le formulaire de connexion est une cible. Il faut réduire les tentatives automatiques, sans bloquer vos utilisateurs.
Réglage n°8: activer une protection contre le brute force, via un plugin reconnu ou via des règles serveur. L’objectif est simple: ralentir, limiter, et tracer.
Réglage n°9: limiter les tentatives et prévoir une procédure de déblocage. Sur un multi-utilisateur, un verrouillage trop agressif peut bloquer un rédacteur en déplacement, et ça finit par contourner la sécurité (création d’un nouvel utilisateur https://gardewp.fr/securite-wordpress/ “temporaire”).5) Renforcer les mots de passe et le modèle d’authentification
La sécurité ne tient que tant que l’authentification ne cède pas.
Réglage n°10: imposer des mots de passe longs et uniques pour tous les comptes. Les campagnes d’attaques tentent encore des combinaisons classiques, et la réutilisation de mots de passe est un poison rapide.
Réglage n°11: activer la double authentification (2FA) pour les comptes administrateurs et éditeurs. Quand un compte admin est compromis, WordPress devient une plateforme de distribution.Réglage n°12: éviter d’utiliser le même compte pour plusieurs personnes, même en équipe. Sur une équipe, j’ai déjà vu un “partage” de connexion conduire à des changements non tracés.
6) Supprimer l’ambiguïté des identifiants
La plupart des bots ciblent des patterns. On ne “magie” pas WordPress, on réduit les signaux.
Réglage n°13: vérifier l’utilisateur admin historique. S’il existe, vous pouvez le renommer (ou créer un nouvel admin puis rétrograder et supprimer).
Réglage n°14: supprimer les comptes inutilisés, notamment ceux créés pour “un test”. Un compte oublié devient un levier à exploiter.Réglage n°15: désactiver ou supprimer l’affichage des erreurs trop verbeuses liées à la connexion, et veiller à ce que le site ne donne pas trop d’informations en cas d’identifiants invalides.
7) Désactiver l’inscription publique et maîtriser la création de comptes
Réglage n°16: désactiver l’inscription si vous n’en avez pas besoin, ou prévoir une validation manuelle stricte. L’inscription publique est une invitation à la création de comptes “pour voir”, puis à l’escalade.
Réglage n°17: si inscription nécessaire, activer une modération et contrôler les rôles attribués. Ne jamais donner “éditeur” par défaut à un nouveau compte.8) Sécuriser la base: préfixe, sauvegardes, et cohérence
La base de données est le centre nerveux. Une compromission ou une corruption peut être fatale, même si la page d’accueil semble intacte.
Réglage n°18: vérifier que le préfixe de tables de base de données n’est pas par défaut. C’est moins critique que les patchs, mais ça réduit certains automatisme.
Réglage n°19: mettre en place des sauvegardes automatiques et testées. La différence entre “avoir des backups” et “pouvoir restaurer” se joue lors d’un incident. Faites un test de restauration sur un environnement de staging.Un piège classique: un backup produit correctement, mais restauré sur un autre PHP ou une autre configuration ça échoue. Le test régulier évite ce stress.
9) Mettre en place un monitoring des changements
Le cœur de la sécurité WordPress, ce sont les signaux: fichiers modifiés, nouveaux utilisateurs, changements inattendus.
Réglage n°20: activer une surveillance d’intégrité (fichiers WordPress et certains dossiers ciblés), ou au minimum un journal d’événements côté plugin de sécurité.
Réglage n°21: surveiller les changements de thèmes, plugins, et la création d’utilisateurs. Déclenchez des alertes sur l’apparition de nouveaux administrateurs.Sur un site où j’avais détecté une modification silencieuse, le plugin de sécurité a signalé un changement de fichier avant que la page front ne montre quoi que ce soit. C’était la différence entre une restauration propre et une semaine d’investigation.
10) Séparer le contenu et la configuration, éviter l’accès direct aux fichiers sensibles
Réglage n°22: s’assurer que les fichiers de configuration et les sauvegardes ne sont pas accessibles publiquement. Cela inclut les fichiers temporaires, certains dossiers d’uploads trop permissifs, et les backups laissés par des outils de migration.
Réglage n°23: restreindre l’accès à wp-config.php et à tout fichier de type “ .sql”, “.zip” ou “*.bak” qui pourrait exister sur la racine. Selon l’hébergement, cela passe par des règles serveur (ou par une configuration via .htaccess si Apache).
11) Utiliser HTTPS et forcer la redirection proprement
Sans HTTPS, la sécurité devient un puzzle incomplet.
Réglage n°24: activer HTTPS partout, et forcer les redirections vers la version sécurisée.
Mettre l’ensemble en cohérence: le “qui fait quoi” pour ne pas se marcher dessus
Une erreur fréquente consiste à empiler des protections sans comprendre leur interaction: un plugin de cache agressif, un firewall qui bloque des URLs, et un plugin de sécurité qui applique des règles trop strictes. On ne gagne pas en sécurité en doublant les couches au hasard.
Dans les faits, je traite la configuration comme un système:
- d’abord, des mises à jour maîtrisées, ensuite, une couche d’authentification (2FA, limites de tentatives), puis une couche de filtrage réseau (firewall ou règles serveur), et enfin la surveillance (logs, alertes, intégrité).
Si vous avez un CDN ou un WAF, intégrez-le. Sinon, vous pouvez obtenir déjà une bonne base avec des plugins de sécurité sérieux, mais gardez la main sur les règles.
Quelques réglages “réalistes” pour éviter les effets secondaires
Beaucoup de personnes veulent “bloquer tout”. Sur WordPress, le blocage total finit par ruiner des fonctionnalités légitimes: appels AJAX, webhooks, formulaires, jobs de synchronisation. Il vaut mieux une politique progressive.
Par exemple:
- si vous activez une limitation des tentatives de connexion, prévoyez un seuil qui tolère les utilisateurs réels, si vous masquez des endpoints ou réduisez l’exposition, vérifiez les plugins qui utilisent REST API, si vous appliquez des règles strictes, testez sur staging pour les pages de connexion, le checkout, et les formulaires.
Sur un site multilingue avec un plugin de traduction, une règle trop large sur les requêtes a cassé l’éditeur et a déclenché une panique interne. La sécurité avait augmenté, mais la fiabilité avait chuté. Ce n’est pas un bon compromis.
Deux checkpoints rapides avant de dire “c’est bon”
Avant de déployer partout, passez par deux validations simples. Elles évitent la majorité des mauvaises surprises.
Check 1 - posture sécurité côté comptes
- comptes: suppression des comptes inutilisés, contrôle des rôles, et 2FA sur les administrateurs. connexion: limitation brute force et logs activés, avec une stratégie de déblocage. mots de passe: aucun partage et pas de réutilisation entre personnes.
Check 2 - posture sécurité côté code et exposition
- mises à jour: WordPress, thèmes, plugins, et PHP alignés et suivis. accès: pas de fichiers sensibles exposés, HTTPS forcé, redirection propre, et configuration de permissions cohérente. surveillance: intégrité et alertes, sauvegardes testées et plan de restauration.
Une manière simple de prioriser si vous n’avez pas tout le temps
Vous pouvez activer les 25 réglages en une fois, mais sur un site actif, je conseille de les prioriser en “impact” et “risque”. D’abord ce qui réduit une compromission directe, puis ce qui améliore la détection et la récupération.
Réglages à effet immédiat sur la compromission:
- mises à jour (WordPress, thèmes, plugins), PHP supporté, 2FA et limites de tentatives, suppression des comptes inutilisés, blocage des accès aux fichiers sensibles.
Réglages à effet immédiat sur la récupération et la détection:
- sauvegardes testées, monitoring des changements, alertes sur nouveaux administrateurs ou modifications inattendues.
Les détails qui font gagner du temps lors d’un incident
Si demain quelqu’un se connecte sans autorisation, votre plan doit déjà exister dans votre tête, et idéalement dans vos outils.
Je recommande de garder:
- une procédure courte pour isoler le site (désactiver plugins, couper certaines règles), un moyen de restauration rapide (staging + backups testés), un historique des derniers changements déployés.
La plupart des équipes perdent du temps parce qu’elles doivent reconstituer “ce qui a changé”. Une bonne discipline de déploiement réduit ce coût, même si l’incident ne vient jamais.
Récapitulatif des 25 réglages à activer dès aujourd’hui
Pour ne pas vous laisser avec une liste mentale trop floue, voici les 25 réglages sous forme de repères, sans vous forcer un style particulier d’exécution.
Réglage n°1: planifier et appliquer les mises à jour WordPress.
Réglage n°2: mettre à jour thème et plugins avec une vérification de compatibilité. Réglage n°3: supprimer plugins inactifs et thèmes inutilisés. Réglage n°4: utiliser une version PHP supportée (typiquement 8.1 ou 8.2). Réglage n°5: configurer des erreurs minimales et des logs exploitables. Réglage n°6: vérifier les permissions des dossiers et fichiers (droits cohérents). Réglage n°7: empêcher l’exécution de scripts dans des dossiers qui ne doivent pas. Réglage n°8: activer une protection anti brute force sur wp-login. Réglage n°9: fixer des limites de tentatives avec déblocage maîtrisé. Réglage n°10: imposer des mots de passe longs et uniques. Réglage n°11: activer la double authentification (2FA) pour les comptes clés. Réglage n°12: éviter de partager un même compte entre plusieurs personnes. Réglage n°13: traiter le compte admin historique (renommer ou remplacer si nécessaire). Réglage n°14: supprimer les comptes inutilisés ou à risque (anciens prestataires). Réglage n°15: réduire les informations trop détaillées lors d’erreurs de connexion. Réglage n°16: désactiver l’inscription publique si elle n’est pas indispensable. Réglage n°17: si inscription nécessaire, modération et rôle minimal. Réglage n°18: vérifier que le préfixe de tables n’est pas par défaut. Réglage n°19: sauvegardes automatiques et restauration testée. Réglage n°20: activer une surveillance d’intégrité ou un suivi des fichiers. Réglage n°21: alerter sur création d’utilisateurs et changements de plugins/thèmes. Réglage n°22: empêcher l’accès public aux fichiers sensibles et aux backups. Réglage n°23: restreindre wp-config.php et tout fichier de type archive ou base. Réglage n°24: forcer HTTPS et rediriger proprement. Réglage n°25: activer les en-têtes de sécurité adaptés, HSTS si tout est stable.Si vous voulez, décrivez votre configuration (hébergeur, usage d’un CDN/WAF, plugins de cache et de sécurité, nombre de contributeurs, et si vous avez l’inscription ouverte). Je peux vous proposer une stratégie d’activation progressive, avec l’ordre des réglages pour minimiser les risques de blocage et éviter les surprises.