Comment sécuriser un site WordPress, étape par étape

↑ Ce conseil fait partie du guide : Piratage d'une entreprise : obligations et réflexes

Comment sécuriser un site WordPress ?

Trois mesures font l'essentiel du travail. Activez les mises à jour automatiques du cœur, des extensions et du thème. Désinstallez tout ce qui ne sert plus, au lieu de le désactiver. Et protégez les comptes administrateurs par un mot de passe unique et la double authentification. Les sauvegardes hors serveur ferment la marche.

Qui attaque un site WordPress, et comment

On imagine quelqu'un qui vous aurait choisi. Dans la réalité, la quasi-totalité des sites de petites entreprises sont attaqués par des scripts automatisés qui balaient le web entier et ne savent même pas à qui appartient le site.

Le déroulé type, tel qu'on le lit dans les journaux d'accès :

1. Le repérage. Un robot interroge quelques adresses connues pour déterminer quel CMS tourne, dans quelle version, et quels plugins sont installés. Cela prend une seconde, et ça se fait sur des millions d'adresses par jour.
2. L'essai. Il rejoue les failles publiées du mois sur les plugins repérés, et teste des identifiants issus de fuites sur la page de connexion. Les pirates ne devinent pas les mots de passe : ils rejouent ceux que d'autres ont déjà perdus.
3. Le dépôt. Dès qu'un essai réussit, un script minuscule est écrit quelque part — souvent dans le dossier des envois — et l'adresse du site part dans une liste.
4. L'exploitation, plus tard. Des jours ou des semaines après, un autre programme revient par cette porte et installe ce qui rapporte : pages de spam, redirection, envoi de courrier indésirable, minage, ou un malware servi à vos propres visiteurs.

Trois conséquences pratiques, et elles commandent tout le reste de cette fiche. Un petit site est visé autant qu'un gros : la sélection ne se fait pas sur l'intérêt commercial, mais sur la faille. Le délai entre l'entrée et les symptômes explique qu'on découvre l'infection des mois après. Et comme l'attaque est automatique, ce qui la bloque est automatique aussi : une version à jour, un mot de passe qui n'est nulle part ailleurs. Il ne s'agit pas d'être malin, il s'agit de ne pas être la cible facile.

Les mises à jour : la protection la plus rentable

C'est le premier réglage, et de très loin le plus efficace. Une faille corrigée ne s'exploite plus ; une faille publiée et non corrigée est testée par des robots dans les heures qui suivent l'annonce publique.

1. Activez les mises à jour automatiques du cœur de WordPress, y compris les versions majeures. Le risque d'une régression existe ; il est sans commune mesure avec celui d'une version abandonnée trois mois.
2. Activez-les plugin par plugin, depuis la colonne dédiée de la liste des extensions. Faites-le aussi pour le thème actif.
3. Vérifiez la version de PHP dans l'espace client de l'hébergeur. Une version en fin de vie ne reçoit plus aucun correctif de sécurité, et beaucoup de sites tournent encore dessus par simple inertie. Le passage à une version récente est une case à cocher chez la plupart des hébergeurs.
4. Regardez la page Santé du site (Outils, puis Santé du site) : elle signale justement la version de PHP, les mises à jour en retard et les modules manquants.

Plugins et thèmes : désinstaller vaut mieux que désactiver

Chaque extension est une porte. Le nombre d'extensions installées est le meilleur indicateur du risque d'un site, devant à peu près tout le reste.

• Désactiver ne suffit pas. Un plugin désactivé reste sur le disque, et ses scripts PHP restent appelables par une adresse directe. Plusieurs compromissions célèbres sont passées par des extensions désactivées depuis des années. On désinstalle.
• Avant d'installer, trois chiffres se lisent sur la fiche de l'extension : la date de la dernière mise à jour (au-delà d'un an, passez votre chemin), le nombre d'installations actives, et la compatibilité annoncée avec votre version de WordPress.
• Jamais de version « nulled », c'est-à-dire un thème ou un plugin payant récupéré gratuitement. La porte dérobée est dans le paquet, dès l'installation : c'est le seul cas où le site est compromis avant même sa première visite. Une licence à quelques dizaines d'euros coûte moins cher qu'une journée de nettoyage.
• Un plugin abandonné par son auteur ne recevra jamais de correctif. Cherchez un remplaçant maintenant, pas le jour où la faille sort.
• Supprimez les thèmes inutilisés, en n'en gardant qu'un de secours fourni par WordPress lui-même.

Une règle simple qui tient dans une phrase : si vous ne savez pas dire à quoi sert une extension, elle ne doit pas être là.

Comptes, rôles et mots de passe : verrouiller l'administration

Le deuxième chemin d'entrée, c'est la page de connexion. Les robots y rejouent des listes d'identifiants issues de fuites publiques, à raison de milliers d'essais par jour sur un site ordinaire.

1. Un seul vrai administrateur, deux au maximum. Les autres passent en éditeur ou en auteur : un compte compromis ne donne alors accès à rien d'installable.
2. Pas de nom d'utilisateur « admin », ni le nom du site, ni votre prénom visible sur les articles. WordPress ne permet pas de renommer un compte : on en crée un nouveau, on lui transfère les contenus, on supprime l'ancien.
3. Un mot de passe unique et long pour chaque compte, conservé dans un gestionnaire de mots de passe. Un mot de passe réutilisé ailleurs et retrouvé dans une fuite ouvre le site sans qu'aucune faille soit nécessaire — le mécanisme est détaillé dans comment les pirates trouvent vos mots de passe.
4. La double authentification sur tous les comptes capables d'installer du code. C'est le réglage qui annule l'effet d'un mot de passe fuité : comment elle fonctionne.
5. La limitation des tentatives de connexion : après cinq essais ratés, l'adresse est bloquée temporairement. Cela ne protège pas d'une attaque ciblée, mais cela élimine la totalité du bruit automatisé.
6. Désactivez l'éditeur de fichiers de l'interface d'administration, par une ligne define('DISALLOW_FILE_EDIT', true); dans wp-config.php. Un compte admin compromis ne peut alors plus injecter de script depuis le navigateur.

Ce qui, en revanche, ne sert presque à rien : masquer l'adresse de la page de connexion. C'est une gêne de trente secondes pour un robot, et une gêne permanente pour vous. Ça ne remplace ni un mot de passe unique ni la double authentification.

L'hébergement : ce qui se règle en dehors de WordPress

Une partie de la sécurité d'un site ne se joue pas dans WordPress, et c'est la partie qu'on oublie le plus souvent.

• Le certificat SSL et le HTTPS forcé. Le certificat chiffre la liaison entre le visiteur et le serveur. Il ne protège pas le contenu du site — un site piraté en HTTPS reste un site piraté — mais son absence décourage les visiteurs et pénalise le référencement. Vérifiez qu'il se renouvelle automatiquement.
• L'isolation des sites. Sur un hébergement mutualisé où vous avez plusieurs sites dans le même compte, un site compromis contamine ses voisins. Séparer les comptes, ou au minimum les dossiers et les bases de données, évite que le plus négligé n'emporte les autres.
• Les droits sur les fichiers : 644 pour les fichiers, 755 pour les dossiers, et jamais 777. Un dossier en écriture pour tout le monde est une invitation.
• Interdire l'exécution des scripts PHP dans le dossier des envois, par une règle dans .htaccess. Ce seul réglage neutralise la majorité des portes dérobées déposées : le fichier est bien écrit, mais il ne s'exécute pas.
• Désactiver XML-RPC si vous ne publiez pas depuis une application mobile. C'est une porte historique, très utilisée pour tester des milliers de mots de passe en une seule requête.
• Protéger wp-config.php par une règle de refus dans .htaccess : ce fichier contient les identifiants de la base de données.

Demandez aussi à votre hébergeur deux choses précises : combien de jours de journaux d'accès il conserve (c'est ce qui permettra de comprendre une intrusion), et s'il fournit des sauvegardes, à quelle fréquence, et comment on les restaure soi-même.

Les accès au serveur : FTP, SSH et la base MySQL

Sous WordPress, il y a un serveur, et trois portes qu'on oublie parce qu'on ne s'en sert que deux fois par an. Elles donnent pourtant un accès plus profond que n'importe quel compte d'administration.

• Le FTP. Il transporte identifiant et mot de passe en clair sur le réseau. Utilisez SFTP (ou FTPS) : la même chose, chiffrée. C'est une case à cocher dans votre logiciel de transfert, et tous les hébergeurs le proposent.
• Les mots de passe enregistrés dans le logiciel de transfert sont stockés dans un fichier de configuration, souvent lisible tel quel. C'est une cible connue des programmes voleurs d'identifiants : un poste infecté livre les accès du serveur sans qu'aucune faille du site ne soit exploitée. Voir détecter un logiciel espion.
• Le SSH, quand l'hébergeur le fournit, vaut mieux qu'un accès FTP : il est chiffré, et il accepte l'authentification par clé plutôt que par mot de passe — beaucoup plus solide. Si vous ne vous en servez pas, demandez à ce qu'il soit fermé.
• La base MySQL. Son utilisateur ne doit avoir de droits que sur sa base, jamais sur toutes celles du compte. Et le préfixe des tables gagne à ne pas être celui d'origine : ça ne bloque pas une attaque ciblée, mais ça met en échec les scripts automatisés qui écrivent leurs redirections en aveugle.
• L'accès à la base par le web (un gestionnaire installé dans un répertoire du site) est à supprimer une fois le travail fini. Un gestionnaire oublié dans un répertoire est une porte ouverte sur l'ensemble des données.

Enfin, faites le tour des répertoires du site : les dossiers de travail d'un ancien prestataire, une copie de sauvegarde laissée à la racine, un fichier d'archive téléchargeable, une ancienne version du site dans un sous-dossier. Ces restes ne sont pas mis à jour, et ce sont eux qu'on retrouve à l'origine des compromissions les plus anciennes.

Pare-feu et scan : ce qu'une extension de sécurité apporte vraiment

Les extensions de sécurité sont utiles, mais elles arrivent après les mises à jour et les mots de passe, jamais à leur place. Ce qu'elles font réellement :

• Un pare-feu applicatif qui filtre les requêtes connues pour exploiter des failles publiées, avant qu'elles n'atteignent le code. C'est leur apport principal, et il est réel, surtout dans la fenêtre entre la publication d'une faille et l'installation du correctif.
• Un scan planifié des fichiers, qui compare le cœur et les extensions à leur version officielle et alerte par courrier électronique dès qu'un fichier est modifié. C'est ce qui fait découvrir une infection en trois jours plutôt qu'en trois mois.
• Le blocage des tentatives de connexion répétées.

Ce qu'elles ne font pas, et qu'il faut savoir : un scanner rate une porte dérobée écrite proprement, qui ressemble à du code légitime ; il rate ce qui est injecté dans la base de données si le scan ne porte que sur les fichiers ; et il produit des faux positifs sur les thèmes commerciaux, qui utilisent souvent du code compressé pour des raisons légitimes — supprimer sans vérifier casse le site.

Les sauvegardes : la mesure qui marche encore quand tout a échoué

Aucune protection n'est absolue. La sauvegarde est la seule qui fonctionne après, et c'est pour ça qu'elle n'est pas négociable.

1. Fichiers ET base de données, les deux. Une sauvegarde de fichiers seule ne restaure ni vos articles, ni vos commandes, ni vos réglages.
2. Hors du serveur. Une sauvegarde stockée sur le même hébergement disparaît avec lui, et un attaquant qui a la main sur le compte peut l'effacer. Un stockage en ligne distinct, ou un téléchargement automatique, règle la question.
3. Plusieurs versions conservées. Si l'infection est découverte trois semaines après, la sauvegarde d'hier contient déjà le problème. Sept quotidiennes, quatre hebdomadaires, douze mensuelles : c'est le schéma qui permet de revenir au dernier état sain plutôt qu'au dernier état tout court.
4. Une restauration testée, une fois. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde. Le site de préproduction de l'hébergeur est l'endroit idéal pour faire ce test sans rien risquer.

Le détail du raisonnement, la règle 3-2-1 et les pièges des supports sont dans la sauvegarde d'une petite entreprise — un site internet est rarement la seule chose qu'il faut pouvoir remonter.

Surveiller : les trois alertes à brancher, et rien de plus

La surveillance ne demande pas un tableau de bord. Trois alertes suffisent, et elles arrivent toutes dans votre boîte mail.

1. L'alerte de fichier modifié, envoyée par l'extension de sécurité après son scan hebdomadaire. C'est celle qui détecte une intrusion réussie.
2. La Search Console. Inscrivez le site et vérifiez que l'adresse mail renseignée est lue : c'est Google qui vous préviendra en premier d'un problème de sécurité, de pages de spam indexées, ou d'un signalement de programme malveillant. C'est gratuit, et c'est l'alerte la plus fiable.
3. Une surveillance de disponibilité, qui interroge le site toutes les cinq minutes et prévient s'il ne répond plus ou s'il devient très lent. Plusieurs services le font gratuitement pour un site.

Et un contrôle manuel, une fois par mois, qui prend deux minutes : tapez site:votredomaine.fr dans le moteur de recherche et regardez si le nombre de pages correspond à ce que vous avez publié. Des centaines d'adresses inconnues, souvent en langue étrangère, c'est le symptôme le plus courant d'un site compromis — le reste des signes est dans mon site WordPress a été piraté.

La check-list, dans l'ordre, à faire ce soir

Dix réglages, du plus rentable au plus fin. Ils tiennent en une soirée et ferment la porte aux attaques automatisées, qui représentent l'écrasante majorité des cas.

1. Mises à jour automatiques du cœur, de tous les plugins et du thème.
2. Désactiver puis désinstaller les plugins et thèmes inutilisés.
3. Version de PHP récente, vérifiée dans l'espace client de l'hébergeur.
4. Un seul administrateur, sans le nom d'utilisateur « admin ».
5. Mot de passe unique et double authentification sur chaque compte administrateur.
6. Limitation des tentatives de connexion.
7. Éditeur de fichiers désactivé dans wp-config.php.
8. Exécution des scripts PHP interdite dans le dossier des envois.
9. Une extension de sécurité — une seule — avec pare-feu et scan hebdomadaire alerté par mail.
10. Sauvegardes automatiques hors serveur, plusieurs versions, restauration testée une fois.

Les trois premières lignes font à elles seules l'essentiel du travail. Si vous ne devez en faire que trois ce soir, ce sont celles-là.

Se faire aider, et à quel prix

Deux situations justifient un regard extérieur. La première : vous héritez d'un site que vous n'avez pas construit, avec des accès incomplets et un thème modifié à la main par plusieurs prestataires. On ne sécurise pas ce qu'on n'a pas inventorié, et l'inventaire est la partie longue. La seconde : le site a déjà été piraté au moins une fois — dans ce cas, la question n'est pas de le protéger mais de vérifier d'abord qu'il est propre, ce qui est traité dans mon site WordPress a été piraté.

Concrètement, la mise en sécurité d'un site ordinaire se fait à distance, sans déplacement : l'assistance à distance démarre à 19 € la demi-heure, et le diagnostic de quinze minutes au téléphone ne coûte rien — il suffit souvent à dire si le site a un vrai problème ou seulement un retard de mises à jour. Le détail est sur la page tarifs et le déroulé sur comment ça se passe.

Questions fréquentes

Une extension de sécurité suffit-elle à protéger un site WordPress ?

Non. Elle ajoute un pare-feu et un scan, ce qui est utile, mais elle ne corrige pas une faille dans un plugin obsolète et ne remplace pas un mot de passe unique. L'ordre d'efficacité est : mises à jour, puis comptes, puis extension de sécurité.

Faut-il désactiver ou désinstaller un plugin dont on ne se sert plus ?

Désinstaller, toujours. Un plugin désactivé reste présent sur le serveur et ses fichiers PHP restent appelables par une adresse directe : plusieurs compromissions sont passées par des extensions désactivées depuis des années.

Masquer l'adresse de connexion protège-t-il vraiment ?

Très peu. C'est une gêne de quelques secondes pour un robot, qui trouve l'adresse par d'autres chemins, et une gêne permanente pour vous. Le temps passé là-dessus est mieux investi dans la double authentification et la limitation des tentatives.

Mon site est petit, suis-je vraiment une cible ?

Oui, autant qu'un gros site. Les attaques sont automatiques et ne sélectionnent pas sur l'intérêt commercial : elles sélectionnent sur la faille. Un site vitrine de trois pages avec un plugin obsolète est une cible plus facile qu'une boutique tenue à jour.

Les mises à jour automatiques risquent-elles de casser mon site ?

Cela arrive, rarement, et c'est réparable. Une sauvegarde automatique déclenchée avant la mise à jour et, pour un site qui fait vivre l'activité, un site de préproduction fourni par l'hébergeur suffisent à couvrir ce risque — qui reste très inférieur à celui d'une version non corrigée.

Combien de temps faut-il pour sécuriser un site existant ?

Comptez une à deux heures pour un site ordinaire dont vous avez tous les accès : mises à jour, ménage dans les extensions, comptes, sauvegardes. Davantage si le site a été repris par plusieurs prestataires, car l'inventaire prend alors plus de temps que les réglages.

À lire aussi : mon site WordPress a été piraté · la sauvegarde d'une petite entreprise · les obligations d'une TPE piratée.