Sécuriser un site WordPress : la checklist sans plugin miracle

Sécuriser un site WordPress ressemble rarement à ce que promet la publicité des extensions. Aucune installation en un clic ne rend un site inviolable, et la plupart des intrusions constatées n’exploitent aucune prouesse technique : elles passent par un composant obsolète, un mot de passe réutilisé ailleurs, un compte oublié depuis deux ans. Les mesures qui protègent vraiment sont peu nombreuses, ennuyeuses et gratuites, ce qui explique probablement leur faible popularité face aux tableaux de bord colorés. La démarche présentée ici les classe par efficacité décroissante, en distinguant ce qui relève du propriétaire du site de ce qui relève de son hébergeur, et se termine par le plan de réaction à préparer avant d’en avoir besoin.

Sécuriser un site WordPress : la hiérarchie des mesures

Toutes les mesures défensives ne se valent pas, et la tentation habituelle consiste à commencer par les plus visibles plutôt que par les plus efficaces. L’ordre ci dessous inverse cette pente.

Les mises à jour dominent la liste pour une raison arithmétique. Une faille publiée devient une cible de masse dans les jours qui suivent sa divulgation, parce que les campagnes automatisées balaient l’ensemble du web à la recherche des installations qui n’ont pas encore appliqué le correctif. Un site tenu à jour sort de ce champ de tir sans rien faire d’autre.

Deux précautions rendent cette routine tenable. La première consiste à activer les mises à jour automatiques pour les correctifs de sécurité du cœur, qui n’introduisent presque jamais de régression. La seconde consiste à traiter manuellement les montées de version majeures des extensions, après sauvegarde, en observant le site derrière. Un site jamais mis à jour par peur de la casse finit toujours par accumuler un retard qui rend la mise à jour bien plus périlleuse que si elle avait été faite au fil de l’eau.

Les sauvegardes occupent la deuxième place parce qu’elles ne préviennent rien mais réparent tout. Trois critères déterminent leur valeur réelle : leur fréquence rapportée au rythme de publication, leur stockage sur un support distinct du serveur qui héberge le site, et leur restauration effectivement testée au moins une fois par trimestre sur un environnement séparé.

Les accès, premier point de rupture

Un identifiant valide traverse toutes les protections applicatives, puisqu’il se présente comme légitime. Cette évidence place la gestion des comptes très haut dans la hiérarchie, largement au dessus de tout durcissement technique.

Le principe de moindre privilège s’applique sans exception. Un rédacteur n’a pas besoin d’installer des extensions, un stagiaire n’a pas besoin de créer des comptes, un prestataire intervenu six mois plus tôt n’a plus besoin d’accéder à quoi que ce soit. WordPress propose une hiérarchie de rôles suffisamment fine pour couvrir la quasi totalité des situations, et l’attribution du rôle d’administrateur devrait rester exceptionnelle.

La revue périodique des comptes constitue l’opération la plus rentable de toute la liste, et la plus négligée. Sur un site de quelques années, elle révèle presque toujours des comptes créés pour une intervention ponctuelle, des accès de développement jamais fermés, parfois un compte de démonstration au mot de passe évident.

La double authentification ajoute une seconde preuve à la connexion, code temporaire généré par une application ou clé physique. Elle neutralise l’essentiel du risque lié aux mots de passe divulgués lors de fuites survenues sur d’autres services, phénomène massif contre lequel aucune règle de complexité ne protège. Son activation sur les comptes disposant de droits élevés devrait précéder toute autre mesure de durcissement.

Les mots de passe uniques complètent le dispositif. Un gestionnaire de mots de passe rend cette discipline praticable, là où la mémoire humaine pousse inévitablement à la réutilisation. La longueur compte davantage que la présence de caractères exotiques, et une phrase longue vaut mieux qu’une suite courte et illisible.

La surveillance des connexions ferme la boucle. Un journal qui conserve la date, l’origine et l’issue de chaque tentative permet de repérer trois signaux utiles : une série d’échecs concentrée sur un compte précis, une connexion réussie à une heure incohérente avec les habitudes de l’équipe, ou l’apparition d’un identifiant qui n’existait pas la semaine précédente. Cette lecture demande quelques minutes par mois et vaut mieux qu’un tableau de bord jamais consulté.

Reste le cas particulier des comptes de service, ces accès créés pour un outil de sauvegarde, une passerelle de paiement ou un connecteur d’analyse. Ils cumulent souvent des droits étendus et une absence totale de surveillance, personne ne s’étonnant qu’ils se connectent à des heures inhabituelles. Les inventorier, documenter à quoi chacun sert, et supprimer ceux dont plus personne ne sait rien fait partie de la revue mensuelle.

Ce qui relève de l’hébergeur

Une partie de la sécurité échappe complètement au propriétaire du site, et il vaut mieux savoir laquelle avant de choisir un prestataire.

L’hébergeur maintient le système d’exploitation et les services du serveur, propose des versions du langage encore supportées, isole les comptes les uns des autres sur les machines partagées, filtre une part du trafic malveillant en amont, et surveille les processus anormaux. Il fournit également, selon les offres, des sauvegardes de niveau serveur et des certificats de chiffrement.

La version de PHP constitue le point de contact le plus concret entre les deux périmètres. L’hébergeur met les versions à disposition, le propriétaire du site décide laquelle utiliser. Rester sur une branche qui ne reçoit plus de correctifs revient à conserver une porte dont on sait qu’elle ne sera plus réparée. Le basculement se teste sur un environnement séparé, puis s’applique en gardant la possibilité de revenir en arrière.

Le certificat de chiffrement et la redirection systématique vers la version sécurisée du site relèvent du même partage : l’hébergeur émet et renouvelle, le site impose la redirection et vérifie qu’aucune ressource ne reste appelée en clair. Les critères qui permettent de juger la solidité d’une offre sur ces points sont détaillés dans notre décryptage de l’hébergement mutualisé et de ses limites.

Le nom de domaine mérite enfin sa propre vigilance. Le verrou de transfert, l’adresse de contact administratif valide et le renouvellement automatique protègent l’actif le plus difficile à récupérer en cas de problème, sujet traité dans notre article sur la gestion du domaine et de la migration.

Réduire la surface d’attaque

Chaque composant installé est une ligne de code supplémentaire susceptible de contenir une faille, et un projet susceptible d’être abandonné par son propriétaire. La réduction de la surface exposée consiste simplement à en avoir moins.

Trois habitudes de désencombrement suffisent. Désinstaller plutôt que désactiver : une extension désactivée reste présente sur le disque et ses fichiers demeurent accessibles. Supprimer les thèmes inutilisés, en n’en conservant qu’un seul en réserve. Écarter les composants dont la dernière mise à jour remonte à plus d’un an, signe fréquent d’abandon, en cherchant une solution maintenue avant que la question ne devienne urgente.

Le choix initial compte autant que l’entretien. Privilégier des extensions largement installées, activement maintenues et documentées réduit statistiquement le risque, tout comme éviter les versions redistribuées gratuitement de logiciels payants, qui constituent un vecteur de compromission bien identifié. Le coût en performance de cette accumulation se cumule d’ailleurs avec le risque, comme l’explique notre article sur les réglages d’une extension de sécurité et ses alternatives.

Réagir à une compromission

Un plan préparé à froid vaut mieux qu’une improvisation à chaud, et la première réaction détermine souvent l’ampleur finale des dégâts.

Isoler d’abord. Basculer le site en maintenance ou le rendre temporairement inaccessible protège les visiteurs, évite un signalement dans les listes de sites malveillants, et empêche l’aggravation. Conserver une copie de l’état compromis avant toute modification permettra ensuite de comprendre.

Restaurer ensuite, à partir d’une sauvegarde antérieure à l’incident, ce qui suppose d’avoir daté la compromission par la lecture des journaux. Restaurer une sauvegarde déjà infectée est l’erreur classique, et elle fait perdre un temps considérable.

Changer alors tous les accès sans exception : comptes WordPress, base de données, panneau de l’hébergeur, transfert de fichiers, bureau d’enregistrement du domaine. Un seul identifiant oublié ramène l’incident quelques jours plus tard.

Comprendre enfin le point d’entrée. Sans cette étape, la restauration ne fait que remettre en place le site tel qu’il était au moment où il a été pris, avec la même faille ouverte. Comparer les dates de modification des fichiers, relire les journaux de connexion et inventorier les composants obsolètes suffit dans la grande majorité des cas.

Deux obligations complètent le volet technique et se traitent avec l’aide d’un conseil compétent. Si des données personnelles ont pu être exposées, le cadre européen impose des démarches et des délais qu’il vaut mieux connaître avant l’incident plutôt que pendant. Prévenir les personnes concernées, quand la situation l’exige, se prépare également à froid, avec un message rédigé d’avance et une adresse de contact opérationnelle. Une compromission mal gérée sur le plan de la communication coûte souvent plus cher que la remise en état technique elle même.

Aucune extension ne remplace cette discipline. Sécuriser un site relève d’une routine tenue dans la durée, pas d’un achat, et cette routine tient en une heure par mois pour un site ordinaire.