La sécurité WordPress ne se résume pas à “installer un plugin” et à espérer que tout ira bien. On sécurise un système vivant: des thèmes qui changent, des plugins mis à jour, des comptes créés par des humains, des hébergeurs qui exposent des services, et des réglages oubliés depuis des années. En pratique, les incidents les plus coûteux viennent rarement d’un exploit unique et spectaculaire. Ils naissent plutôt d’un empilement de petites décisions: un compte admin partagé, une mise à jour repoussée, un mot de passe trop simple, des droits trop larges, une sauvegarde non testée, et une identification brouillonne en cas d’incident.
Voici 50 réglages concrets, dans l’ordre où je les ferais sur un site réel, avec des arbitrages et des pièges à connaître.
Le socle: ce qui évite 80% des surprises
Réglage 1 : activez et appliquez le principe du moindre privilège. Sur WordPress, chaque compte doit avoir uniquement les droits dont il a besoin. Un éditeur n’a pas à gérer les plugins, un auteur n’a pas à installer des thèmes.
Réglage 2 : limitez les rôles “dangereux”. Si possible, réduisez le nombre de comptes avec le rôle administrateur à une petite équipe. Sur beaucoup de sites, j’ai vu 5 à 15 comptes “admin” parce que “c’est plus simple pour travailler”. C’est précisément ce qui agrandit la surface d’attaque.
Réglage 3 : mettez en place une politique de mots de passe exigeante, unique par personne. WordPress n’a pas de magie ici, c’est la discipline qui compte: gestionnaire de mots de passe, suppression des mots de passe réutilisés, rotation quand un compte a été compromis.
Réglage 4 : supprimez ou désactivez les comptes inutilisés. Un ancien développeur parti depuis trois ans reste parfois actif. Avant de “durcir” le site, nettoyez ce qui n’a plus de raison d’être.
Réglage 5 : verrouillez l’accès à l’administration par un périmètre réseau si c’est possible (IP allowlist, VPN d’équipe, ou au minimum restriction par pays sur un pare-feu applicatif). Je ne le conseille pas partout, mais quand c’est compatible avec votre organisation, le gain est immédiat.
Réglage 6 : assurez-vous que l’URL d’administration n’est pas accessible sans contrôle additionnel. WordPress a ses endpoints standard (comme /wp-login.php). Si vous utilisez un plugin de masquage, considérez-le comme une couche de réduction du bruit, pas comme une sécurité complète.
Réglage 7 : remplacez les identifiants “à l’ancienne” par des identifiants non devinables. Le couple “admin/admin” ou “admin” comme nom d’utilisateur a la vie dure dans les migrations.
Réglage 8 : utilisez HTTPS correctement, avec redirection stricte. Une configuration partielle (certificat ok, mais cookies non sécurisés) peut ouvrir des scénarios de session fragiles, surtout sur des réseaux publics.
Réglage 9 : vérifiez les en-têtes de sécurité côté serveur quand vous le pouvez (HSTS, headers de base). WordPress peut aider via configuration serveur, mais l’hébergeur reste souvent le point central.
Réglage 10 : choisissez des thèmes et plugins minimalistes. Un thème trop “baroque” ou un constructeur de pages ajouté pour un besoin ponctuel finit par devenir un facteur de risque et de maintenance.
Mises à jour: le levier le plus rentable (si vous le faites bien)
Réglage 11 : gardez WordPress à jour, y compris les versions mineures. Les correctifs de sécurité ne sont pas toujours dans les grosses nouveautés visibles. Souvent, les versions “mineures” contiennent des correctifs qui changent vraiment la donne.
Réglage 12 : mettez à jour les plugins et thèmes avec un calendrier clair. Le piège classique: vous mettez à jour les deux ou trois plugins “importants” et vous laissez quatre plugins dormants.
Réglage 13 : retirez les plugins et thèmes inutilisés. Supprimer l’extension inactive, c’est réduire l’attaque et simplifier vos audits. Désactiver seulement, c’est parfois conserver des fichiers exploitables.
Réglage 14 : testez les mises à jour sur un environnement de préproduction avant de déployer sur le site public. Sur un site e-commerce ou un annuaire, une mise à jour “sans test” peut casser des fonctionnalités, et l’urgence pousse ensuite les gens à contourner la sécurité.
Réglage 15 : bloquez les mises à jour automatiques pour les composants à risque si votre process ne suit pas derrière. Sur certains sites, laisser les automatisations sans supervision crée d’autres problèmes. L’objectif n’est pas “automatique”, c’est “maîtrisé”.
Réglage 16 : retirez les vieux composants PHP ou bibliothèques. Un serveur qui tourne sur une ancienne version de PHP est un risque structurel, même si le site “fonctionne”. Les durcissements modernes comptent sur des versions récentes.
Accès et authentification: durcir sans casser les humains
Réglage 17 : activez l’authentification à deux facteurs (2FA) pour tous les comptes ayant accès à l’administration. Le gain est énorme contre le vol de session et le phishing, tant que vos utilisateurs utilisent correctement l’outil choisi.
Réglage 18 : limitez les tentatives de connexion. Un mécanisme de rate limiting via votre pare-feu applicatif ou un plugin dédié réduit drastiquement le brute force. L’erreur fréquente: se limiter à WordPress, alors que le trafic arrive avant, via le serveur.
Réglage 19 : surveillez les tentatives échouées. Un pic de “login failed” est souvent le premier symptôme. La surveillance vous donne une chance d’agir avant que le compte ne soit compromis.
Réglage 20 : désactivez l’accès à l’édition de fichiers depuis WordPress si votre gouvernance le permet. Beaucoup d’attaques prennent de l’élan via l’édition de code. Sur un site maintenu sérieusement, ce n’est pas un mode de travail à conserver.
Réglage 21 : bloquez les utilisateurs “pas vraiment administrateurs” d’accéder aux écrans sensibles. Ajustez les rôles, même si cela demande de clarifier le workflow. Une erreur de droits, c’est un incident probable.
Réglage 22 : imposez une gestion de session prudente. Sur un site multi-utilisateurs, forcez une politique d’expiration cohérente pour limiter les sessions longues en cas d’oubli.
Réglage 23 : nettoyez les sessions “fantômes”. Quand des comptes changent de poste, supprimez les sessions actives. WordPress conserve des traces en fonction de la configuration et de l’authentification, et un attaquant aime les anciennes sessions.
Sécuriser l’interface et les contenus: éviter les scripts et les redirections
Réglage 24 : désactivez l’upload de types de fichiers non nécessaires. Autoriser tous les formats revient à inviter des vecteurs d’attaque. Si vous n’avez pas besoin de SVG, n’en autorisez pas l’import, et traitez les documents autorisés avec parcimonie.
Réglage 25 : vérifiez et sécurisez les paramètres d’upload. Un mauvais réglage peut laisser passer des fichiers exécutables ou des scripts dissimulés. Faites-le de pair avec un durcissement côté serveur.
Réglage 26 : limitez les permissions de “média” et d’accès aux fichiers par rôle. Un auteur ne doit pas pouvoir publier n’importe quel contenu technique si votre objectif est de réduire les erreurs.
Réglage 27 : imposez une politique stricte sur les utilisateurs capables d’installer des plugins. Si vous avez un plugin de formulaire ou de SEO “crucial”, il ne doit pas dépendre d’une installation aléatoire par un utilisateur.
Réglage 28 : contrôlez les redirections et les champs qui acceptent des URLs. Une partie des compromissions injectent des liens externes ou modifient des pages existantes.
Réglage 29 : traitez la question du “contenu user-generated”. Si vous avez des commentaires ou des formulaires, appliquez des mesures anti-spam et vérifiez les réglages de modération. Le spam n’est pas qu’un problème esthétique, c’est un vecteur de charge sur votre site et parfois une porte d’entrée à d’autres comportements.
Plugins: réduire la surface d’attaque sans perdre la valeur
Réglage 30 : limitez le nombre de plugins. Une règle pragmatique: chaque plugin ajouté doit avoir un propriétaire, un besoin clair, et une date de réévaluation.
Réglage 31 : supprimez les plugins “qui font semblant”. Certains “security plugins” ajoutent surtout des alertes ou des réglages confus, sans réduire réellement le risque. Je préfère une stratégie basée sur le pare-feu et les contrôles d’accès, plus fiables.
Réglage 32 : vérifiez la réputation et la maintenance des plugins. Regardez la fréquence des mises à jour et la réactivité face aux rapports de bugs. Pas besoin d’entrer dans des débats, mais un plugin abandonné devient un risque.
Réglage 33 : configurez la sécurité côté pare-feu applicatif si possible. Wordfence et ses équivalents peuvent aider, mais le meilleur endroit pour bloquer reste souvent avant WordPress, via votre système de filtrage.
Réglage 34 : désactivez les fonctionnalités inutiles des plugins installés. Beaucoup proposent des options qui augmentent l’exposition (par exemple, logs trop verbeux, API ouvertes, endpoints inutilisés).
Réglage 35 : surveillez les modifications de fichiers. Un plugin de sécurité peut afficher des alertes, mais l’essentiel est d’avoir un flux de réponse: qui regarde, qui confirme, qui rollback.
Thème: durcir sans casser le rendu
Réglage 36 : évitez d’installer plusieurs “builders” de page. Les constructeurs multiplient les composants, les templates, et parfois les scripts chargés.
Réglage 37 : utilisez un thème enfant si vous devez customiser. Modifier le thème parent, c’est garantir des surprises lors des mises à jour, et souvent des contournements “rapides” qui finissent par être des vulnérabilités.
Réglage 38 : supprimez les scripts et modules non nécessaires. Un thème qui charge des bibliothèques partout, même sur les pages qui ne les utilisent pas, augmente la surface d’attaque et complique les audits.
Réglage 39 : vérifiez l’existence de backdoors ou de code suspect dans les fichiers de thème. Je n’insiste pas sur l’idée de “hack évident”, car les compromissions modernes sont souvent discrètes.
Réglage 40 : minimisez l’édition manuelle de code côté WordPress. Si vous devez le faire, encadrez-le. Idéalement, tout changement passe par un workflow versionné.
Base de données, préfixes, et fichiers WordPress: la prudence technique
Réglage 41 : utilisez un préfixe de base de données non standard lorsque c’est possible. WordPress permet un préfixe différent lors de l’installation, mais si le site est déjà en place, ce n’est pas un “réglage magique” facile à changer sans risques. L’objectif est la réduction du bruit, pas une promesse de sécurité.
Réglage 42 : limitez l’exposition des erreurs. En production, évitez d’afficher les erreurs PHP ou SQL aux visiteurs. Les messages peuvent divulguer des chemins de fichiers, versions, ou https://gardewp.fr/securite-wordpress/ détails utiles à un attaquant.
Réglage 43 : configurez les permalinks de façon cohérente et stable. Un changement de structure peut exposer des comportements inattendus, surtout si des règles de sécurité ou de cache ne suivent pas.
Réglage 44 : verrouillez les droits de fichiers côté système. Typiquement, les fichiers ne doivent pas être exécutables quand ce n’est pas nécessaire, et les dossiers n’ont pas besoin d’être en écriture pour tout le monde. Les valeurs exactes dépendent de votre environnement, et c’est là qu’il faut avancer prudemment.
Réglage 45 : contrôlez l’intégrité des fichiers WordPress et du thème. L’attaque la plus frustrante est celle qui remplace un morceau de code sans casser immédiatement le site. Avoir une référence aide à détecter rapidement.
Hébergement, réseau et transport: là où se joue souvent la bataille
Réglage 46 : choisissez un hébergement qui isole les utilisateurs. Les environnements partagés peuvent convenir au départ, mais le risque augmente quand il n’y a pas de bonnes politiques d’isolation et de mises à jour.
Réglage 47 : activez un WAF et un anti-bot si votre trafic le justifie. Sans rentrer dans les slogans, bloquer tôt réduit l’impact des attaques. Sur un site très exposé, c’est souvent la meilleure dépense.
Réglage 48 : configurez correctement le cache. Un mauvais cache peut servir des contenus injectés si la configuration est fragile. Plus vous avez de caches, plus vous devez valider les invalidations et les headers.
Réglage 49 : gérez les sauvegardes avec test. Sauvegarder ne suffit pas si vous ne savez pas restaurer. Je recommande de tester une restauration sur un environnement de staging au moins de façon périodique, pas uniquement “quand ça va mal”.
Réglage 50 : documentez la réponse à incident. Qui change quoi, où sont les logs, comment on coupe l’accès, comment on restaure, qui informe l’équipe. Sur une attaque réelle, les minutes gagnées viennent d’un plan existant, pas de l’improvisation.
Deux vérifications qui évitent la fausse tranquillité
Quand on a “tout réglé”, il reste deux questions simples: est-ce que c’est vraiment actif, et est-ce que vous savez quoi faire si ça tourne mal ? Pour rester concret, voici deux mini-checklists.
- Vérifications de sécurité à faire avant de considérer le site “stable” Confirmez que 2FA est bien activé pour chaque compte à accès admin Vérifiez que la restriction d’accès brute force et le filtrage des IP sont bien actifs Contrôlez que les mises à jour critiques sont planifiées, avec un responsable Testez la restauration d’une sauvegarde sur un environnement de préproduction Inspectez 3 à 5 thèmes et plugins “métier” pour repérer ce qui est inutile ou abandonné Vérifications rapides après un changement majeur (thème, plugin, migration) Vérifiez les pages sensibles, notamment celles qui touchent aux formulaires ou à l’authentification Contrôlez les fichiers modifiés récemment, pour repérer des changements inattendus Regardez les logs de sécurité et le volume de tentatives de connexion Testez un parcours complet d’un utilisateur non admin (comment il agit, ce qu’il voit) Vérifiez que les droits fichiers et la configuration serveur n’ont pas dérivé
Le point d’équilibre: sécurité forte, mais utilisable
La sécurité WordPress efficace n’est pas celle qui bloque tout le monde. C’est celle qui protège sans créer une usine à gaz. Par exemple, une restriction d’IP à l’administration peut être excellente pour une petite équipe, mais pénible pour des freelances ou des déplacements. Une politique de mise à jour trop stricte peut entraîner des retards, donc un risque plus élevé sur la durée.
Pareil pour les plugins de sécurité: ils peuvent être utiles pour l’alerte et le filtrage, mais ils peuvent aussi masquer des problèmes ailleurs, notamment sur le serveur ou dans les droits de fichiers. J’ai déjà vu des équipes se reposer sur un plugin “anti-hack” alors que les sauvegardes n’étaient pas restaurables. Quand l’incident arrive, la sécurité qui compte, c’est la capacité à revenir en arrière et à identifier ce qui s’est passé.
Si vous devez commencer par 10 réglages, lesquels choisir ?
Si votre liste de 50 réglages ressemble à une montagne, faites un premier sprint orienté impact. Le but n’est pas d’être parfait, mais de couper les scénarios les plus courants. Pour beaucoup de sites, le meilleur point de départ consiste à verrouiller l’accès (comptes, rôles, 2FA, tentatives), à aligner les mises à jour (WordPress, plugins, thème), puis à sécuriser la restauration (sauvegardes testées).
Réfléchissez aussi à votre organisation: si vous n’avez pas de cycle de maintenance, alors les choix doivent pousser vers un système “qui se protège quand vous n’êtes pas en train de surveiller”. Dans la pratique, cela veut souvent dire pare-feu, limitation brute force, et discipline sur les comptes.
Ces 50 réglages couvrent le terrain, du plus quotidien au plus technique, et surtout, ils couvrent les endroits où les incidents naissent vraiment. Si vous en appliquez seulement une partie aujourd’hui, commencez par ce qui réduit immédiatement le risque d’accès et ce qui vous permet de restaurer sans panique. Ensuite, enchaînez, pas à pas, jusqu’à ce que la sécurité devienne un réflexe plutôt qu’un projet d’urgence.