Administrer et sécuriser un site WordPress

Administrer un site WordPress, c'est installer le CMS proprement, donner à chaque utilisateur les droits dont il a besoin et pas plus, choisir et mettre à jour le cœur, le thème et les extensions, sauvegarder et savoir restaurer. Le sécuriser, c'est appliquer ces gestes avec méthode, durcir la configuration et savoir reconnaître et traiter un site compromis. Ce chapitre suit la remise à niveau du site de la Cyclerie et s'appuie sur les dix recommandations de l'ANSSI pour la mise en œuvre sécurisée d'un CMS.

Comment fonctionne WordPress

WordPress est une application PHP qui stocke ses contenus et ses réglages dans une base MySQL ou MariaDB. À chaque visite, le serveur web exécute le code de WordPress, qui lit la base, applique le thème et les extensions, et renvoie une page HTML.

WordPress recommande aujourd'hui PHP 8.3 ou plus, MariaDB 10.11 ou MySQL 8.0 ou plus, et un hébergement avec HTTPS. Une version de PHP qui n'est plus maintenue expose le site à des failles même si WordPress est à jour : c'est une des premières choses à vérifier dans l'interface de l'hébergeur.

Installer proprement

Sur un hébergement mutualisé, l'installation se fait souvent en un clic depuis l'interface de l'hébergeur. Que tu l'installes ainsi ou à la main, les bons réflexes sont les mêmes :

1. Activer HTTPS avant l'installation, pour que l'adresse du site soit enregistrée en https:// dès le départ.
2. Créer une base et un utilisateur dédiés au site, avec un mot de passe long et aléatoire, et seulement les droits sur cette base.
3. Ne pas nommer le compte administrateur « admin » : c'est le premier identifiant essayé par les robots qui testent des mots de passe. Associe-le à une adresse générique de l'organisation ou du prestataire.
4. Installer en français et régler le fuseau horaire, la langue et le format de date dans Réglages.
5. Supprimer les thèmes et extensions installés par défaut dont tu n'as pas besoin, et le contenu d'exemple.

Sur un serveur où tu as un accès SSH, l'outil en ligne de commande WP-CLI automatise et documente l'installation. Ses commandes sont faciles à reporter dans une procédure :

# Télécharger WordPress en français dans le dossier du site
wp core download --locale=fr_FR

# Créer wp-config.php (le mot de passe de la base est demandé, il n'apparaît pas dans l'historique)
wp config create --dbname=cyclerie --dbuser=cyclerie_wp --prompt=dbpass

# Installer : WP-CLI génère un mot de passe administrateur aléatoire et l'affiche une seule fois
wp core install --url=https://www.cyclerie-des-saules.fr --title="Cyclerie des Saules" \
  --admin_user=ondine-admin --admin_email=web@ondine-informatique.example

Le mot de passe affiché va directement dans le gestionnaire de mots de passe du prestataire ; il ne s'envoie pas par courriel.

Utilisateurs et rôles

WordPress attribue à chaque compte un rôle, c'est-à-dire un ensemble de capacités. C'est l'application directe du principe du moindre privilège (cours authentification).

Le piège classique : donner le rôle Administrateur à tout le monde « pour que ça marche ». Or un administrateur peut installer une extension, donc exécuter du code sur le serveur ; un seul compte administrateur compromis suffit à prendre le contrôle du site. Léo construit pour la Cyclerie la matrice suivante, validée par la gérante :

Chaque personne a son propre compte : un compte partagé empêche de savoir qui a fait quoi et oblige à changer le mot de passe pour tout le monde au départ d'une seule personne. Les comptes des personnes qui partent sont désactivés ou supprimés le jour même, après avoir attribué leurs contenus à un autre compte.

Thèmes et extensions : moins, mais mieux

Chaque extension est du code tiers, exécuté sur le serveur avec les mêmes droits que WordPress. La grande majorité des failles publiées chaque année concernent des extensions et des thèmes, pas le cœur. D'où une règle simple : le moins d'extensions possible, et seulement des extensions activement maintenues.

Avant d'installer une extension, vérifie :

• la date de dernière mise à jour et la compatibilité annoncée avec la version de WordPress ;
• le nombre d'installations actives, les avis et la réactivité du support ;
• l'éditeur : extension du répertoire officiel, éditeur connu, historique des failles et de leur correction ;
• le besoin réel : WordPress fait peut-être déjà ce qu'on veut (plan du site XML, éditeur de blocs, favicon), ou une extension déjà installée le couvre.

Une extension désactivée reste sur le serveur : ses fichiers peuvent encore être appelés directement si elle contient une faille. On supprime ce qui ne sert pas. Et on n'installe jamais un thème ou une extension premium « gratuits » trouvés sur un site de téléchargement : ces copies piratées contiennent souvent une porte dérobée.

# Lister les extensions inactives, puis les supprimer après vérification
wp plugin list --status=inactive --field=name
wp plugin delete nom-de-l-extension

# Lister les comptes administrateurs pour vérifier qu'il n'y a que les bons
wp user list --role=administrator --fields=ID,user_login,user_email

Chez la Cyclerie, Léo passe de 23 extensions à 7 : un formulaire de contact, la prise de rendez-vous de l'atelier, la double authentification, la sauvegarde, la mesure d'audience, une extension de référencement et une protection contre le spam des formulaires.

Mettre à jour sans casser le site

WordPress installe automatiquement les mises à jour mineures (correctifs de sécurité, par exemple de 7.0 à 7.0.1). Les mises à jour majeures, celles des extensions et des thèmes se déclenchent depuis le tableau de bord ou en ligne de commande, et peuvent aussi être rendues automatiques extension par extension.

Une mise à jour peut casser un site : extension incompatible, thème qui n'affiche plus correctement une page. La procédure qui limite le risque :

1. Sauvegarder les fichiers et la base, et vérifier que la sauvegarde est complète.
2. Lire les notes de version des mises à jour importantes.
3. Tester sur une préproduction (une copie du site, souvent fournie par l'hébergeur) pour les mises à jour majeures.
4. Appliquer en production, à un moment de faible trafic.
5. Vérifier les pages clés : accueil, formulaire de contact, prise de rendez-vous, connexion à l'administration.
6. Consigner la mise à jour dans le journal de maintenance : date, versions, problèmes rencontrés.

wp core check-update
wp plugin list --update=available
wp core update && wp core update-db
wp plugin update --all
wp theme update --all

Sauvegarder et savoir restaurer

Une sauvegarde de WordPress comprend deux parties : la base de données et le dossier wp-content (plus wp-config.php). Une sauvegarde qui n'a jamais été restaurée n'est qu'une supposition.

• Fréquence : quotidienne pour la base si le site change souvent, au minimum avant chaque mise à jour.
• Lieu : au moins une copie hors du serveur (chez un autre prestataire de stockage) : si le site est compromis ou si l'hébergeur a un incident, une sauvegarde stockée au même endroit est perdue avec lui.
• Conservation : plusieurs générations (par exemple 30 jours), pour pouvoir revenir à un état d'avant une compromission découverte tard.
• Test : une restauration sur la préproduction chaque trimestre, notée dans le journal.

# Export de la base (à compléter par une copie de wp-content et wp-config.php)
wp db export sauvegarde-cyclerie-2026-11-02.sql

La règle 3-2-1 et les tests de restauration sont détaillés dans le cours sauvegarde et PRA.

Les recommandations de l'ANSSI appliquées à WordPress

L'ANSSI a publié en décembre 2023 une fiche « Les Essentiels » consacrée à la mise en œuvre sécurisée d'un CMS. Voici ses dix bonnes pratiques et leur traduction concrète pour un site WordPress :

Durcir la configuration

Quelques réglages de wp-config.php et du serveur réduisent la surface d'attaque :

// Interdire la modification des fichiers de thème et d'extension depuis l'administration
define( 'DISALLOW_FILE_EDIT', true );

// Ne jamais afficher les erreurs PHP aux visiteurs en production
define( 'WP_DEBUG', false );

// Forcer HTTPS pour l'administration
define( 'FORCE_SSL_ADMIN', true );

• DISALLOW_FILE_EDIT retire l'éditeur de fichiers du tableau de bord : un attaquant qui a volé un compte administrateur ne peut plus y coller du code en deux clics.
• Droits des fichiers : en général 755 pour les dossiers, 644 pour les fichiers, et wp-config.php lisible seulement par l'utilisateur du serveur (640 ou 600 selon l'hébergement).
• Clés secrètes : wp-config.php contient des clés qui signent les cookies de session. Les renouveler (wp config shuffle-salts) déconnecte tout le monde : c'est un geste à faire après une compromission.
• Interfaces inutilisées : l'interface XML-RPC (xmlrpc.php) sert à d'anciennes applications de publication ; si personne ne l'utilise, on la désactive, par l'hébergeur ou une règle du serveur web.
• Tentatives de connexion : limiter les essais répétés sur la page de connexion, par l'hébergeur ou une extension.

Reconnaître un site compromis et réagir

Un site WordPress compromis n'affiche pas toujours une page de revendication. Les symptômes les plus fréquents :

• des pages de spam (pharmacie, casinos, contrefaçons) indexées par Google sous le domaine de l'organisation, visibles dans la Search Console ou en cherchant le nom du domaine dans un moteur ;
• des redirections vers d'autres sites, parfois seulement pour les visiteurs sur mobile ou venant de Google, pour que l'administrateur ne les voie pas ;
• un compte administrateur inconnu, des extensions que personne n'a installées ;
• des fichiers PHP dans wp-content/uploads, un dossier qui ne devrait contenir que des médias ;
• une alerte « Problèmes de sécurité » dans la Search Console, un avertissement du navigateur (« site trompeur ») ou un message de l'hébergeur qui a suspendu le site ;
• des courriels de spam envoyés depuis le serveur.

# Comparer les fichiers du cœur et des extensions du répertoire officiel avec les originaux
wp core verify-checksums
wp plugin verify-checksums --all

La réaction suit la logique de la gestion d'incident (cours réponse aux incidents) :

1. Contenir : mettre le site en maintenance ou le faire suspendre par l'hébergeur, sans tout effacer.
2. Préserver les traces : copie des fichiers, de la base et des journaux, pour comprendre par où l'attaquant est entré.
3. Couper les accès : changer tous les mots de passe (administration, SFTP, base, hébergeur, bureau d'enregistrement), renouveler les clés secrètes, supprimer les comptes inconnus.
4. Assainir : restaurer une sauvegarde antérieure à la compromission, ou réinstaller le cœur et les extensions depuis leurs sources officielles, puis tout mettre à jour.
5. Corriger la cause : l'extension vulnérable, le mot de passe faible, l'absence de double authentification.
6. Revenir en ligne et surveiller : demander un réexamen dans la Search Console, surveiller les journaux.
7. Évaluer les obligations : si des données personnelles ont pu être consultées (comptes clients, formulaires), c'est une violation de données à notifier à la CNIL dans les 72 heures quand elle présente un risque pour les personnes (droit du numérique).

Exercices