Sécuriser WordPress durablement : la checklist après la faille 7.0.2

Le correctif est posé. Le vrai travail commence.

Tu as mis à jour vers WordPress 7.0.2 (ou 6.9.5, ou 6.8.6). La faille critique wp2shell est fermée. Parfait.

Maintenant la question qui compte : que se passe-t-il la prochaine fois ? Parce qu’il y aura une prochaine fois. Pas parce que WordPress serait mal fait, mais parce que c’est le fonctionnement normal de tout logiciel largement déployé.

La différence entre un site qui encaisse et un site qui tombe ne se joue pas sur la gravité de la faille. Elle se joue sur ce qui était en place avant qu’elle ne soit publiée. Voici cette checklist.

1. Les sauvegardes (le seul point vraiment non négociable)

Si tu ne devais faire qu’une chose, ce serait celle-là. Une sauvegarde propre transforme une catastrophe en contretemps.

Les critères d’une sauvegarde qui sert réellement :

• Automatique. Une sauvegarde manuelle est une sauvegarde qu’on oublie.
• Quotidienne au minimum, plus fréquente si tu vends en ligne.
• Complète : fichiers et base de données. L’un sans l’autre ne sert à rien.
• Stockée ailleurs. Une sauvegarde sur le même serveur que le site disparaît avec lui.
• Avec de la profondeur : garde plusieurs jours d’historique. Si une compromission date de dix jours et que tu ne gardes que la dernière nuit, tu restaures le problème.
• Testée. C’est le point que tout le monde saute. Une sauvegarde jamais restaurée est une hypothèse, pas une garantie.

Fais le test une fois : restaure ta sauvegarde sur un site de test et vérifie que tout fonctionne. Le jour où tu en auras besoin, tu sauras que ça marche et tu sauras comment faire.

2. Les comptes utilisateurs

Passe en revue Comptes puis Tous les comptes :

• supprime les comptes qui ne servent plus (ancien prestataire, stagiaire parti, développeur de passage) ;
• vérifie que le rôle Administrateur est réservé à ceux qui en ont réellement besoin. Un rédacteur n’a pas besoin d’être administrateur ;
• évite le nom d’utilisateur admin, encore présent sur beaucoup de sites anciens ;
• active l’authentification à deux facteurs sur les comptes administrateurs. C’est la mesure au meilleur rapport effort/protection.

Un compte administrateur inutilisé, c’est une porte ouverte que personne ne surveille.

3. Les extensions

C’est de loin la première source de compromission des sites WordPress, bien avant le cœur.

• Supprime ce que tu n’utilises pas. Un plugin désactivé reste présent sur le serveur, avec son code. Désactivé n’est pas supprimé.
• Vérifie la date de dernière mise à jour de chaque plugin. Un plugin sans mise à jour depuis deux ans est un risque, même s’il fonctionne.
• Méfie-toi des plugins téléchargés hors des canaux officiels, en particulier des versions premium « offertes ». C’est un vecteur d’infection classique.
• Limite le nombre. Chaque extension ajoute du code, des routes d’API et une dépendance de plus.

Une règle simple : si tu ne sais pas dire à quoi sert un plugin, il ne devrait pas être là.

4. La version de PHP

Va dans Outils puis Santé du site, onglet Informations, section Serveur.

PHP est le langage qui fait tourner WordPress. Les versions anciennes ne reçoivent plus de correctifs de sécurité, quel que soit l’état de ton WordPress.

Si ton hébergeur te laisse en PHP 7.x, change la version depuis le panneau d’hébergement, après sauvegarde et de préférence après avoir testé sur une copie. Le gain est double : sécurité et performance.

5. Un pare-feu applicatif

Un WAF (Web Application Firewall) filtre les requêtes avant qu’elles n’atteignent WordPress. C’est ce qui te protège pendant la fenêtre entre la publication d’une faille et le moment où tu appliques le correctif.

Deux approches :

• au niveau de l’hébergement : beaucoup d’hébergeurs sérieux en proposent un, parfois inclus ;
• en frontal : un service qui reçoit le trafic avant ton serveur, avec limitation de débit et blocage des schémas d’attaque connus.

Cherche au minimum : limitation du nombre de requêtes par IP, protection de la page de connexion, et blocage des tentatives d’injection.

6. La surveillance

Le point le plus souvent absent, et pourtant décisif. Sans surveillance, tu apprends que ton site est cassé par un client, ou par Google.

Le minimum utile :

• surveillance de disponibilité : une alerte si le site ne répond plus ;
• alerte de mise à jour : un e-mail quand une mise à jour de sécurité est disponible ou appliquée ;
• contrôle d’intégrité des fichiers : une alerte si un fichier du cœur change alors que tu n’as rien fait ;
• Google Search Console configurée, section Sécurité et actions manuelles consultée de temps en temps.

Ces quatre points sont accessibles gratuitement ou pour presque rien.

7. Les accès techniques

• Change les mots de passe FTP et base de données s’ils datent de la livraison du site.
• Vérifie qui a encore accès à ton panneau d’hébergement et à ton registrar de nom de domaine.
• Assure-toi que tu es bien propriétaire du nom de domaine, et pas ton ancienne agence. Ce point ne concerne pas directement la sécurité, mais c’est le genre de découverte qui fait mal au pire moment.

8. Ce qu’il ne faut pas faire

Trois faux amis rencontrés régulièrement :

• Empiler les plugins de sécurité. Deux plugins de sécurité qui se marchent dessus protègent moins bien qu’un seul bien réglé, et ralentissent le site.
• Bloquer aveuglément des routes ou des fonctions trouvées dans un article, sans comprendre ce qu’on coupe. On casse des choses qui ne se verront que des semaines plus tard.
• Désactiver les mises à jour automatiques pour « éviter les problèmes ». C’est exactement le raisonnement qui laisse un site vulnérable trois mois après la publication d’un correctif.

Faut-il rester sur WordPress ?

Question honnête, réponse honnête : oui, dans la plupart des cas.

WordPress a bien géré cette affaire : faille signalée par des chercheurs, correctif publié rapidement, mises à jour forcées pour protéger les sites qui ne suivent pas. C’est le signe d’un projet sérieusement maintenu.

WordPress reste pertinent si tu publies beaucoup de contenu, si plusieurs personnes doivent modifier le site, ou si tu dépends d’un écosystème d’extensions.

En revanche, si ton site est une vitrine qui bouge trois fois par an, tu payes un coût de maintenance et une surface d’attaque pour des fonctionnalités que tu n’utilises pas. Un site statique moderne n’a ni base de données à injecter, ni extensions à mettre à jour, ni administration à protéger. Ce n’est pas magique et ça ne convient pas à tout le monde, mais sur ce profil, c’est plus simple et plus sûr.

Le bon critère n’est pas la mode, c’est l’usage réel de ton site.

Par où commencer si tu ne fais qu’une chose cette semaine

Dans l’ordre d’impact :

1. Sauvegardes automatiques externalisées et testées.
2. Mises à jour de sécurité automatiques activées.
3. Ménage dans les comptes administrateurs et les plugins inutilisés.

Le reste peut attendre le mois prochain. Ces trois points-là, non.

Si tu veux un état des lieux de ton site sur ces critères, on le fait en moins d’une heure et on te dit ce qui mérite d’être corrigé en priorité. Écris-nous.