Sécurité WordPress : rôles utilisateurs, authentification à deux facteurs et protection de la connexion
1. Commencez par recenser les comptes : la plupart des sites ont trop d’administrateurs
La première étape d’une intrusion WordPress, c’est toujours la page de connexion. Et pour la franchir, l’attaquant doit disposer d’un couple identifiant-mot de passe valide. Le point de départ de la sécurité n’est donc pas d’installer une extension, mais de compter précisément combien de personnes peuvent accéder au back-office.
Beaucoup de sites accumulent en deux ans sept ou huit comptes administrateur : prestataires, anciens collègues, comptes de test, parfois avec 123456 comme mot de passe. Si l’un d’eux fuite, c’est la porte du back-office grande ouverte.
Exemple concret : un site s’est retrouvé avec des liens frauduleux, et les logs ont montré une connexion depuis un compte de prestataire parti six mois plus tôt. La personne était partie, le compte était resté, avec le mot de passe envoyé à l’époque dans une conversation. L’attaquant n’a eu besoin d’aucune faille.
Pour savoir comment organiser les comptes lors du choix de la stack technique, voir Stack technique pour un site WordPress indépendant ; pour la procédure de nettoyage après une intrusion, voir Après un piratage de site.
| Rôle | Périmètre des droits | À qui l’attribuer |
|---|---|---|
| Administrator | Tout le site : installer des extensions, modifier le code, supprimer des utilisateurs | La personne qui gère réellement le site, ≤2 |
| Éditeur | Gérer tout le contenu et les commentaires | Responsable du contenu |
| Auteur | Écrire et gérer uniquement ses propres articles | Auteurs de contributions |
| Contributeur | Rédiger des brouillons sans pouvoir publier | Rédacteurs externes |
| Abonné | Commenter uniquement | Visiteurs simples |
2. Privilèges minimaux : ne laissez pas quelqu’un qui écrit des articles installer des extensions
Le principe des droits est simple : ce qu’un compte peut faire doit correspondre exactement au minimum nécessaire à son travail. Un rédacteur qui publie des articles n’a pas besoin d’installer des extensions ni de modifier le thème ; un rôle Editor ou Author suffit. Seule la personne qui maintient réellement le site mérite un rôle Administrator.
Le départ d’un collaborateur se gère en deux temps : commencez par réduire ses droits et désactiver le compte, observez une à deux semaines pour vérifier qu’aucune tâche automatisée n’en dépend, puis supprimez-le. Une suppression immédiate peut faire perdre l’attribution d’auteur de ses articles.
Supprimez aussi le nom d’utilisateur admin par défaut. Beaucoup d’outils de brute force testent admin dès le premier essai : si votre back-office l’utilise encore, c’est la moitié du mot de passe offerte.
Le mot de passe lui-même doit être assez long. Huit chiffres, face au cassage moderne, revient à ne rien avoir. Pour un compte administrateur, visez au moins douze caractères, avec majuscules, minuscules et symboles, et ne réutilisez jamais la même chaîne d’un compte à l’autre. La réutilisation de mot de passe est la première cause de réussite du credential stuffing.
| Poste | Rôle conseillé | À ne pas accorder |
|---|---|---|
| Webmaster / responsable technique | Administrator | — |
| Rédacteur de contenu | Éditeur | Installer des extensions, modifier le code |
| Rédacteur | Auteur | Modifier les articles des autres, changer le thème |
| Auteur externe | Contributeur | Publier directement |
| Stagiaire / temporaire | Contributeur | Aucun droit de publication |
Trois. L’authentification à deux facteurs : une serrure en plus du mot de passe
L’authentification à deux facteurs (2FA) sert à ceci : même si le mot de passe fuite, l’attaquant ne peut pas se connecter sans le code dynamique de votre téléphone. C’est la couche la plus efficace contre le credential stuffing, car cette attaque repose justement sur un mot de passe divulgué ailleurs.
Choisissez une application TOTP (Google Authenticator, Authy et autres), pas les SMS. Un code par SMS peut être intercepté par détournement de carte SIM, alors que le TOTP est généré localement, sans dépendre de l’opérateur.
L’obligation se fait en deux temps : imposez-la immédiatement au rôle Administrator, sans quoi la connexion est refusée ; accordez deux semaines de délai aux autres rôles, puis verrouillez automatiquement. Voir Renforcement de la sécurité pour la configuration.Renforcement de la sécurité d’un site indépendant.
Cas concret 3 : une équipe de cinq personnes, au départ seul le responsable technique avait activé le 2FA. Un e-mail a divulgué le mot de passe de la personne chargée de l’exploitation ; l’attaquant est tombé sur l’administration, et comme ce compte n’avait pas de 2FA, la seconde serrure n’existait pas. Deux semaines plus tard, tout le monde l’a activé et ce risque a vraiment été éliminé.
| Méthode 2FA | Sécurité | Ce qu’on recommande |
|---|---|---|
| Application TOTP | Élevée, générée localement sans réseau | À recommander pour tous |
| Code par SMS | Moyenne, détournable via la carte SIM | Déconseillé comme méthode principale |
| Code par e-mail | Faible, l’e-mail fuite souvent avec le mot de passe | En secours uniquement |
| Clé matérielle | Maximal | En option pour les administrateurs |
Quatre. Protection de la connexion : limiter et bloquer sert plus que changer l’URL
Il faut corriger une idée reçue. Beaucoup de tutoriels vous font renommer /wp-admin en un chemin bizarre, en pensant que l’attaquant ne trouvera plus l’administration. En réalité, un attaquant ciblé scanne et repère la page de connexion ; changer le chemin ne fait que compliquer un peu la tâche, sans arrêter le cassage.
Deux mesures sont vraiment efficaces : bloquer l’IP pendant un moment après 5 échecs de connexion (15 minutes par exemple), pour enrayer le cassage automatisé ; désactiver la méthode de publication système XML-RPC, porte d’entrée de nombreux scripts de cassage en masse.
Cas concret 2 : dans les journaux, une IP avait essayé 800 mots de passe en une heure, avec des identifiants tous courants. Une fois le blocage après 5 échecs activé, cette IP a été stoppée dès la sixième tentative, et toutes les suivantes ont été refusées instantanément.
Autre détail : faites répondre légèrement plus lentement l’interface de connexion à chaque échec, et le coût d’un script qui teste des mots de passe en masse grimpe. Quand le site grandit, placez un WAF cloud devant la couche de connexion : le credential stuffing distribué est bloqué avant même d’atteindre WordPress.
| Action de protection | Rôle | Limites |
|---|---|---|
| Bloquer l’IP après 5 échecs | Enrayer le cassage automatisé | Une attaque distribuée exige un WAF cloud |
| Désactiver XML-RPC | Bloquer l’entrée des scripts automatisés | À conserver si vous publiez via l’app |
| Masquer la version de WP | Ne pas exposer les failles des anciennes versions | Réduit seulement l’exposition d’informations |
| Changer le chemin de l’admin | Ajoute un léger coût de scan | N’arrête pas une attaque ciblée |
| Désactiver l’édition de fichiers depuis l’admin | Empêche de modifier le thème après une intrusion | Passez par SFTP pour modifier le code |
5. Les compléments : sauvegardes, supervision et surface d’attaque minimale
Même avec une sécurité impeccable, partez du principe qu’un jour vous serez compromis : la sauvegarde est votre dernier filet. Sauvegardez la base de données et les fichiers séparément, stockez-les hors site et testez une restauration chaque trimestre. Une sauvegarde irrécupérable ne sert à rien. Méthode détaillée dans Stratégie de sauvegarde pour un site indépendant.
La surface d’attaque doit se réduire en continu : supprimez les extensions et les thèmes inutilisés, car chaque extension dormante est une faille potentielle. La supervision doit alerter sur les connexions anormales, par exemple un administrateur qui se connecte depuis une région inhabituelle ou en dehors des heures de travail. Seuils de supervision dans Système de supervision pour un site indépendant.
Une règle absolue : dès qu’un mot de passe a fuité ailleurs, changez tous les mots de passe de tous les comptes du site. Le credential stuffing testera ce mot de passe sur votre admin, et toutes les protections précédentes tombent dès que le mot de passe est correct.
| Action | Fréquence | Critère de conformité |
|---|---|---|
| Recenser les comptes administrateurs | Mensuel | administrateur ≤ 2 |
| Auditer les extensions et thèmes inutilisés | Trimestriel | Désactivé = supprimé |
| Test de restauration de sauvegarde | 1 fois par trimestre | Restaurer en 2 heures |
| Alerte de connexion anormale | Temps réel | Notification immédiate en cas de connexion hors zone |
| Rotation des mots de passe | Immédiatement après une fuite | Tous changent de mot de passe et activent la 2FA |
FAQ — Questions fréquentes
Une extension de sécurité WordPress suffit-elle ?
Changer /wp-admin en un autre chemin suffit-il à arrêter les hackers ?
La double authentification par SMS, ça marche ?
Que faire du compte WordPress d’un salarié qui part ?
Combien de comptes Administrator faut-il garder ?
À quoi ressemble une attaque par force brute dans les journaux ?
Pour conclure
La sécurité WordPress est contre-intuitive : on croit qu’elle dépend de plugins complexes et de règles savantes, alors que ce qui décide du sort du site, c’est d’avoir supprimé les administrateurs superflus et ajouté une deuxième serrure à chaque compte. Ces deux mesures ne coûtent rien et bloquent la grande majorité des intrusions.
Trois étapes concrètes : dès aujourd’hui, faites l’inventaire des utilisateurs et ramenez le nombre d’administrator à 2 maximum ; imposez la double authentification TOTP à tous les administrateurs ; activez le verrouillage après 5 échecs de connexion et désactivez XML-RPC. Ensuite, auditez les comptes chaque mois et faites un exercice de restauration chaque trimestre.
Une phrase à retenir : la sécurité, ce n’est pas de multiplier les serrures sophistiquées, c’est d’abord de récupérer les clés de ceux qui ne devraient pas en avoir.