Sécuriser WordPress : l'ordre dans lequel cela en vaut la peine
Qui cherche « sécuriser WordPress » trouve des listes de vingt points. Le problème n'est pas que ces points seraient faux, mais qu'ils figurent côte à côte, avec le même poids. Les trois premiers apportent plus que les dix-sept autres réunis.
Priorité 1 : les mises à jour, et sans tarder
La plupart des sites compromis ne tombent pas sous une attaque sophistiquée, mais à cause d'une faille connue dans un plugin, pour laquelle une mise à jour existe depuis des semaines. Les scans automatisés de masse cherchent précisément cela.
Concrètement : mises à jour de sécurité automatiques, mises à jour fonctionnelles à la main après une brève vérification — et avant chaque mise à jour, un point de sauvegarde, pour que la crainte de la mise à jour ne devienne pas une raison de la repousser.
Un plugin qui n'a reçu aucune mise à jour depuis deux ans est un risque, même s'il fonctionne. Profitez-en pour faire le ménage : ce qui n'est pas utilisé doit être supprimé, pas désactivé.
Priorité 2 : la connexion
La deuxième porte la plus fréquente est un mot de passe. Quatre mesures, dans cet ordre :
- Limiter les tentatives échouées — cela ôte leur fondement aux tentatives automatisées pour deviner les mots de passe.
- Imposer des mots de passe robustes, au moins pour tous ceux qui ont le droit de publier.
- Activer un second facteur, au moins pour les administrateurs.
- Aucun compte avec le nom d'utilisateur « admin », et aucun rôle plus élevé que nécessaire.
Déplacer l'adresse de connexion est un cinquième point, mais plus faible : il tient les scans de masse à distance et économise de la charge, mais ne remplace aucune des quatre mesures ci-dessus. Qui l'utilise devrait noter la nouvelle adresse avant d'enregistrer.
Priorité 3 : le durcissement — à régler une fois, puis à oublier
- Désactiver l'édition de fichiers dans l'administration — c'est là que le code malveillant est le plus volontiers déposé
- Désactiver XML-RPC si rien n'en a besoin
- Empêcher le listage des répertoires
- Interdire l'exécution de PHP dans le dossier uploads
- Restreindre l'énumération des utilisateurs via l'API REST
- Définir des en-têtes de sécurité
Ces interrupteurs ne coûtent rien à l'usage et ferment chacun un raccourci connu. Ils offrent le meilleur rapport effort-bénéfice de toute la liste.
Priorité 4 : voir ce qui change
À partir d'ici, il ne s'agit plus d'empêcher, mais de remarquer. Deux choses en valent la peine :
La comparaison du cœur confronte les fichiers de WordPress aux sommes de contrôle d'api.wordpress.org. Un fichier du cœur modifié est un signe très clair — personne n'a de raison légitime d'y changer quoi que ce soit.
La surveillance des fichiers enregistre un état de référence et signale les écarts. Elle ne vaut que ce que vaut le moment de cet enregistrement : un état de référence enregistré après une infection fait du code malveillant l'état normal.
Enregistrez l'état de référence tant que le site est sain, preuve à l'appui — idéalement juste après une installation neuve ou après une restauration vérifiée.
Priorité 5 : pare-feu et analyse
Les deux sont utiles et les deux figurent délibérément ici, en bas. Un pare-feu en PHP ne s'exécute que lorsque WordPress démarre déjà — il ne remplace pas un pare-feu en amont du serveur web. Une analyse trouve ce qui ressemble à ses motifs, pas tout code malveillant.
Plus important que le nombre de règles : la gestion des fausses alertes. Un outil dont la vue d'ensemble reste en permanence au rouge ne protège plus rien — il habitue à ignorer les alertes d'un clic. Laissez donc d'abord le pare-feu se contenter de signaler pendant une semaine et parcourez le journal avant de le laisser bloquer.
Ce qui figure souvent tout en haut et n'a rien à y faire
| Mesure | Pourquoi elle est surestimée |
|---|---|
| Masquer la version de WordPress | Un attaquant teste simplement la faille |
| Déplacer l'adresse de connexion | Tient les scans à distance, ne remplace pas un mot de passe fort |
| Un très grand nombre de règles de pare-feu | Plus de règles, c'est plus de fausses alertes, pas plus de protection |
| Plugin de sécurité sans sauvegarde | Après une infection, c'est la voie de retour qui compte, pas l'alarme |
Le point que presque toutes les listes oublient
Un plugin de sécurité prévient les incidents, une sauvegarde leur survit. Qui devrait choisir entre les deux devrait prendre la sauvegarde — c'est la seule mesure qui aide encore quand toutes les autres ont échoué.
Questions fréquentes
Ai-je vraiment besoin d'un plugin de sécurité ?
La protection de mon hébergeur suffit-elle ?
Comment savoir si mon site est infecté ?
Que faire en premier si quelque chose s'est produit ?
À quelle fréquence dois-je vérifier tout cela ?
Kakapo Security — payez une fois, utilisez pour toujours.
Les neuf extensions pour 149 € une fois au lieu de 13 € par mois. Paiement sécurisé via Stripe. Pendant les 14 premiers jours : problème résolu ou remboursé.
Obtenir Lifetime Toutes les fonctionnalités