Comment sécuriser une base de données WordPress : renforcement, chiffrement et protection continue

Chaque site WordPress fonctionne sur une base de données. Elle contient vos articles, vos utilisateurs, leurs mots de passe, les paramètres de vos extensions et les commandes de vos clients.

Les fichiers sur le serveur contiennent votre thème et vos images. La base de données contient tout le reste.

C'est pourquoi c'est la première chose qu'un attaquant sérieux vise.

L'injection SQL est toujours un vecteur d'attaque courant pour WordPress. Les attaquants envoient des entrées spécialement conçues via les formulaires de connexion, les champs de recherche ou les champs d'extensions vulnérables qui trompent la base de données pour qu'elle exécute des commandes qu'elle ne devrait pas.

Une injection réussie peut créer de nouveaux comptes administrateur, rediriger vos visiteurs vers des sites de spam, injecter du code malveillant dans votre contenu ou effacer entièrement la base de données.

La plupart de ces attaques ne font aucun bruit. Le code injecté et les comptes administrateur non autorisés peuvent rester silencieusement dans une base de données pendant des semaines avant que quelque chose de visible ne se passe mal.

J'ai travaillé sur des sites où toutes les extensions étaient mises à jour, l'authentification à deux facteurs activée et des mots de passe forts partout. Ils ont quand même été touchés via une connexion à la base de données que personne n'avait sécurisée.

C'est le sujet de ce tutoriel.

Vous suivrez 13 étapes pour sécuriser votre base de données : les huit premières renforcent la base de données elle-même et ferment les chemins d'attaque les plus courants, et les cinq dernières mettent en place la couche de sauvegarde, de surveillance et de récupération qui vous protège lorsque le renforcement seul ne suffit pas.

À la fin, vous aurez une protection proactive et continue de votre base de données en place.

Voici les points clés à retenir :

• Les 13 étapes couvrent deux couches : le renforcement de la base de données (Étapes 1-8) et la configuration de la sauvegarde, de la surveillance et de la récupération (Étapes 9-13). Vous avez besoin des deux, car le renforcement seul ne vous protège pas après une violation.
• Certaines violations de base de données ne présentent pas de symptômes visibles pendant des jours ou des semaines, la surveillance via l'extension Activity Log est donc aussi importante que le renforcement de la sécurité.
• Un fichier de sauvegarde non chiffré dans le stockage cloud est une copie de votre base de données entière. Toute personne ayant accès à ce compte de stockage peut le lire sans jamais toucher à votre site en direct — le chiffrement à l'étape 9 comble cette lacune.
• Effectuez une sauvegarde complète du site avant de commencer l'étape 1. Plusieurs étapes apportent des modifications directes à la base de données qui sont difficiles à annuler sans cela.
• Enregistrez votre URL de récupération d'urgence Duplicator quelque part en dehors de WordPress pendant l'étape 11. C'est le seul outil qui vous permet de revenir lorsque votre tableau de bord est complètement verrouillé, mais seulement si vous l'avez stocké avant que les choses ne tournent mal.
• La section de dépannage couvre six scénarios de défaillance, y compris un chemin de récupération complet lorsque votre site ne répond pas et que votre tableau de bord WordPress ne se charge pas.

Table des matières

Qu'est-ce qu'une base de données WordPress ?

WordPress stocke tout le contenu dynamique de votre site dans une base de données. Lorsqu'une personne visite votre site, WordPress interroge la base de données, récupère le contenu pertinent et assemble la page à la volée. Si vous modifiez un paramètre, publiez un article ou ajoutez un utilisateur, cela est enregistré dans la base de données.

Une installation WordPress vierge crée 12 tables principales. Voici ce que contiennent les plus importantes :

• wp_posts : chaque article, page, révision et type de publication personnalisé de votre site
• wp_users : tous les comptes utilisateurs, noms d'utilisateur et mots de passe hachés
• wp_usermeta : rôles utilisateurs, capacités et préférences de compte
• wp_options : paramètres globaux du site, configurations de plugins et données du thème actif
• wp_comments : tous les commentaires des visiteurs et leurs métadonnées

Les plugins et les thèmes ajoutent leurs propres tables en plus des tables par défaut de WordPress. Une boutique WooCommerce ajoute des tables pour les commandes, les produits et les données clients. Un plugin de formulaire ajoute des tables pour chaque soumission.

Plus vous développez sur WordPress, plus votre base de données s'agrandit.

Pourquoi vous devez sécuriser votre base de données WordPress

La base de données est un point de défaillance que tout pirate informatique sérieux vise. Tout ce qui vaut la peine d'être volé ou détruit s'y trouve.

L'injection SQL est toujours une méthode d'attaque courante. Un pirate envoie des entrées soigneusement conçues via un formulaire de connexion, une boîte de recherche ou un champ de plugin vulnérable. Si l'entrée n'est pas correctement assainie, la base de données la traite comme une commande et l'exécute.

À partir de là, le pirate peut lire et exporter toute votre base de données, créer de nouveaux comptes administrateur, injecter du contenu malveillant dans vos articles ou tout supprimer d'un coup.

Votre fichier wp-config.php est l'autre cible majeure. Il contient le nom de votre base de données, votre nom d'utilisateur et votre mot de passe en texte brut. Un pirate qui obtient ce fichier n'a pas besoin de votre connexion WordPress. Il se connecte directement à la base de données et contourne complètement WordPress.

Ce qui surprend la plupart des propriétaires de sites, c'est le silence de ces violations. Les comptes administrateur non autorisés et le code injecté ne cassent généralement rien de visible immédiatement. Au moment où vous remarquez les redirections de spam ou le contenu dégradé, le pirate a souvent accès depuis des semaines.

C'est pourquoi le renforcement de la sécurité seul ne suffit pas. Vous avez également besoin d'un moyen de détecter les modifications et de récupérer à partir d'une sauvegarde propre lorsque quelque chose passe à travers.

Ce dont vous avez besoin avant de commencer

Avant d'apporter des modifications, assurez-vous d'avoir tout ce qui suit en place. Sauter l'étape de sauvegarde en particulier a causé des problèmes à beaucoup de personnes lors d'étapes comme la modification du préfixe de table. Le risque n'en vaut pas la peine.

• Accès au panneau de contrôle d'hébergement. Vous devrez vous connecter à cPanel, MyKinsta, au tableau de bord WP Engine, ou à tout autre panneau fourni par votre hébergeur. Plusieurs étapes impliquent phpMyAdmin, qui se trouve généralement dans la section Bases de données de votre panneau de contrôle.
• Accès FTP ou gestionnaire de fichiers. Vous aurez besoin d'un moyen de visualiser et de modifier les fichiers sur votre serveur, en particulier wp-config.php. La plupart des hébergeurs fournissent un gestionnaire de fichiers directement dans le panneau de contrôle.
• Vos identifiants de base de données actuels. Ouvrez wp-config.php et localisez les valeurs DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Vous y ferez référence dans les étapes 3 à 5.
• Une sauvegarde complète du site effectuée avant de commencer. Utilisez un plugin de sauvegarde comme Duplicator ou créez une sauvegarde manuelle. Assurez-vous d'avoir des copies des fichiers de votre site et de votre base de données. Certaines de ces étapes modifient directement votre base de données, et vous avez besoin d'un point de restauration propre si quelque chose tourne mal.
• Accès administrateur à WordPress. Vous devrez être connecté en tant qu'administrateur pour plusieurs étapes de ce tutoriel.

Comment sécuriser votre base de données WordPress

Je vais vous donner 13 étapes faciles pour sécuriser votre base de données WordPress avant qu'une attaque ne se produise.

Les huit premières renforcent la base de données elle-même et ferment les chemins d'attaque les plus courants. Les étapes 9 à 13 mettent en place la couche de sauvegarde, de surveillance et de récupération qui vous protège lorsque le renforcement seul ne suffit pas.

Voici un aperçu de ce que vous ferez :

• Étape 1 : Changer le nom d'utilisateur et l'ID d'administrateur par défaut. Supprimez les deux identifiants les plus ciblés dans les attaques automatisées de WordPress.
• Étape 2 : Changer le préfixe des tables de la base de données par défaut. Remplacez le préfixe prévisible wp_ que les scripts d'injection SQL ciblent.
• Étape 3 : Créer un utilisateur de base de données dédié avec des privilèges limités. Réduisez votre utilisateur de base de données aux quatre autorisations dont WordPress a réellement besoin.
• Étape 4 : Désactiver les connexions à distance à la base de données. Fermez l'accès externe à votre base de données au niveau de la configuration MySQL.
• Étape 5 : Protéger votre fichier wp-config.php. Verrouillez le fichier qui stocke vos identifiants de base de données en texte brut.
• Étape 6 : Activer le SSL pour les connexions à la base de données. Chiffrez les données en transit entre WordPress et MySQL s'ils s'exécutent sur des serveurs séparés.
• Étape 7 : Ajouter un pare-feu d'application Web. Filtrez les tentatives d'injection SQL avant qu'elles n'atteignent votre base de données.
• Étape 8 : Nettoyer les tables de plugins abandonnés. Supprimez les tables orphelines laissées par les plugins désinstallés qui gonflent votre base de données et comportent des vulnérabilités non corrigées.
• Étape 9 : Configurer des sauvegardes chiffrées. Activez le chiffrement AES-256 afin que vos fichiers de sauvegarde ne puissent pas être lus sans votre clé, même si quelqu'un les télécharge directement.
• Étape 10 : Planifier des sauvegardes automatiques de la base de données. Supprimez l'erreur humaine de votre routine de sauvegarde afin d'avoir toujours un point de restauration récent, quelle que soit l'affluence.
• Étape 11 : Stocker les sauvegardes hors site. Obtenez des copies hors de votre serveur afin qu'une violation au niveau de l'hébergeur ne puisse pas anéantir vos options de récupération.
• Étape 12 : Surveiller les modifications de la base de données. Détectez la création de comptes administrateur non autorisés et les modifications non autorisées en temps réel.
• Étape 13 : Tester une restauration de base de données. Confirmez que votre plan de récupération fonctionne avant d'en avoir besoin.

Étape 1 : Changer le nom d'utilisateur et l'ID d'administrateur par défaut

WordPress crée un utilisateur avec le nom d'utilisateur « admin » et un ID de 1 lors de l'installation. Ces deux valeurs sont intégrées dans presque tous les scripts automatisés de force brute et d'injection SQL qui ciblent WordPress. Les modifier supprime deux des cibles les plus prévisibles de votre base de données.

Voici une méthode simple pour changer votre nom d'utilisateur administrateur sans toucher à la base de données :

1. Créez un nouveau compte administrateur directement dans WordPress
2. Connectez-vous en tant que ce nouvel utilisateur
3. Supprimez le compte administrateur d'origine
4. Réattribuez son contenu au nouveau compte

Si vous devez effectuer le changement directement dans la base de données, voici comment procéder via phpMyAdmin.

Connectez-vous à phpMyAdmin depuis votre panneau de contrôle d'hébergement, sélectionnez votre base de données WordPress dans la barre latérale gauche et cliquez sur l'onglet SQL. Exécutez les requêtes suivantes une par une :

UPDATE wp_users SET user_login = 'yournewname' WHERE user_login = 'admin';

UPDATE wp_users SET ID = 101 WHERE ID = 1;

UPDATE wp_posts SET post_author = 101 WHERE post_author = 1;

UPDATE wp_usermeta SET user_id = 101 WHERE user_id = 1;

Les quatre requêtes sont nécessaires. Votre ID utilisateur apparaît dans wp_users, wp_posts et wp_usermeta, donc la mise à jour de la première table laisse des références brisées dans les deux autres.

Un avertissement avant d'exécuter quoi que ce soit : faites une sauvegarde complète d'abord. Une faute de frappe dans une requête SQL directe peut casser votre site d'une manière difficile à annuler sans sauvegarde.

J'aime utiliser Duplicator pour cela. Il dispose de préréglages de sauvegarde faciles à utiliser qui vous donnent des copies rapides de votre base de données ou de votre site entier.

Duplicator a les meilleurs outils de restauration parmi tous les plugins de sauvegarde que j'ai essayés. Vous verrez comment ils fonctionnent plus tard dans ce tutoriel !

Pour confirmer que le changement a fonctionné, déconnectez-vous de WordPress et reconnectez-vous avec votre nouveau nom d'utilisateur. Votre tableau de bord devrait se charger exactement comme avant.

Étape 2 : Changer le préfixe des tables de la base de données par défaut

WordPress nomme chaque table de base de données avec un préfixe wp_ par défaut. Les scripts d'injection SQL qui ciblent WordPress sont construits autour de cela.

Changer le préfixe pour quelque chose d'imprévisible n'arrêtera pas un attaquant sophistiqué à lui seul, mais cela retire votre site du pool de cibles que les outils automatisés frappent lors de la première passe.

Il y a deux façons de faire cela : utiliser un plugin de sécurité (recommandé pour la plupart des utilisateurs) ou effectuer les changements manuellement via phpMyAdmin.

Méthode par plugin (recommandé)

La méthode par plugin est le choix le plus sûr pour les débutants car elle gère automatiquement les données sérialisées. Certaines tables d'options de plugin stockent le préfixe dans des données PHP sérialisées, et une recherche et remplacement SQL brute peut casser ces données si elle n'est pas gérée avec soin.

All-In-One Security inclut un outil de préfixe de base de données avec des protections intégrées.

Installez le plugin choisi, naviguez vers sa section d'outils de base de données et exécutez le changement de préfixe à partir de là. Le plugin mettra à jour wp-config.php, renommera toutes les tables et gérera les références de données sérialisées en une seule passe.

Méthode manuelle

Si vous préférez changer votre préfixe de table de base de données manuellement, suivez ces étapes.

Premièrement, ouvrez wp-config.php via FTP ou le gestionnaire de fichiers et mettez à jour la ligne $table_prefix avec votre nouveau préfixe. Utilisez uniquement des lettres, des chiffres et des underscores :

$table_prefix = 'site82_';

Deuxièmement, connectez-vous à phpMyAdmin, sélectionnez votre base de données WordPress et ouvrez l'onglet SQL. Exécutez une requête RENAME TABLE pour chaque table de votre base de données :

RENAME TABLE wp_posts TO site82_posts;

RENAME TABLE wp_users TO site82_users;

Repeat this for all 12 core tables and any tables added by plugins.

Ensuite, mettez à jour la table wp_options, qui contient des lignes faisant toujours référence à l'ancien préfixe dans la colonne option_name :

UPDATE site82_options SET option_name = REPLACE(option_name, 'wp_', 'site82_') WHERE option_name LIKE 'wp_%';

Enfin, mettez à jour la table wp_usermeta pour la même raison :

UPDATE site82_usermeta SET meta_key = REPLACE(meta_key, 'wp_', 'site82_') WHERE meta_key LIKE 'wp_%';

Vérifiez vos plugins actifs après avoir exécuté ces requêtes. Certains plugins stockent le préfixe dans leurs propres lignes de données et nécessitent également leur mise à jour. Si quelque chose semble cassé, votre sauvegarde avant modification est le moyen le plus rapide de revenir à un état fonctionnel.

Pour confirmer que tout a fonctionné, visitez la page d'accueil de votre site, puis déconnectez-vous et reconnectez-vous à votre tableau de bord WordPress. Les deux devraient fonctionner exactement comme avant.

Étape 3 : Créer un utilisateur de base de données dédié avec des privilèges limités

Lors de l'installation de WordPress, la plupart des configurations d'hébergement créent un utilisateur de base de données avec un accès administratif complet sur l'ensemble de la base de données. WordPress n'a généralement besoin que de quatre autorisations de base pour fonctionner : SELECT, INSERT, UPDATE et DELETE. Chaque autorisation supplémentaire pourrait créer un risque supplémentaire.

Si un attaquant exploite une vulnérabilité de plugin et obtient l'accès à vos identifiants de base de données, des privilèges limités font la différence entre la lecture de vos données et la suppression de votre base de données entière.

Il y a deux façons d'aborder cela : restreindre les privilèges de l'utilisateur de base de données existant ou créer un nouvel utilisateur dédié avec uniquement les autorisations dont WordPress a besoin.

Restreindre les privilèges via phpMyAdmin

Connectez-vous à phpMyAdmin, cliquez sur Comptes d'utilisateurs en haut, trouvez votre utilisateur de base de données WordPress dans la liste, et cliquez sur Modifier les privilèges. Décochez tout sauf SELECT, INSERT, UPDATE et DELETE. Faites défiler vers le bas et cliquez sur OK pour enregistrer.

Créer un nouvel utilisateur dédié via SQL

Si vous préférez une configuration propre, exécutez ces requêtes dans l'onglet SQL de phpMyAdmin :

CREATE USER 'wpuser_secure'@'localhost' IDENTIFIED BY 'StrongPasswordHere';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser_secure'@'localhost';

FLUSH PRIVILEGES;

If you create a new user, update your wp-config.php file with the new credentials:

define('DB_USER', 'wpuser_secure');

define('DB_PASSWORD', 'StrongPasswordHere');

Une note importante : certains plugins et les mises à jour majeures du cœur de WordPress nécessitent des autorisations CREATE ou ALTER pour ajouter ou modifier des tables de base de données lors de l'installation. Si l'installation d'un plugin échoue après cette étape, ré-accordez temporairement ces autorisations, terminez l'installation, puis révoquez-les à nouveau.

Si vous exécutez plusieurs sites WordPress sur le même serveur, utilisez une base de données complètement séparée et un utilisateur de base de données séparé pour chacun d'eux. Si un site est compromis, ce confinement empêche l'attaquant d'atteindre les autres.

Pour confirmer que les autorisations sont correctement définies, créez un brouillon d'article dans WordPress, enregistrez-le, puis supprimez-le. Si les trois actions réussissent, votre utilisateur de base de données a ce dont il a besoin et rien de plus.

Étape 4 : Désactiver les connexions de base de données à distance

Dans la plupart des configurations WordPress, WordPress et MySQL s'exécutent sur le même serveur. Il n'y a aucune raison d'autoriser les IP externes à se connecter directement à votre base de données. Laisser l'accès à distance ouvert signifie qu'un attaquant peut tenter de s'authentifier auprès de MySQL depuis n'importe où sur Internet, en contournant complètement WordPress.

Il y a deux endroits pour fermer cela, et vous devriez vérifier les deux.

Configuration MySQL

Si vous gérez votre propre serveur (VPS ou hébergement cloud), localisez votre fichier de configuration MySQL. Il se trouve généralement dans /etc/mysql/mysql.conf.d/mysqld.cnf. Trouvez la ligne bind-address et vérifiez qu'elle est définie sur 127.0.0.1 :

bind-address = 127.0.0.1

Si elle est définie sur 0.0.0.0, changez-la en 127.0.0.1 et redémarrez MySQL pour appliquer la modification :

sudo systemctl restart mysql

Nom d'hôte de l'utilisateur de la base de données

Même si MySQL est lié à localhost, il est utile de confirmer que votre utilisateur de base de données WordPress est également restreint aux connexions locales au niveau de l'utilisateur.

Dans phpMyAdmin, cliquez sur Comptes d'utilisateurs et trouvez votre utilisateur de base de données WordPress. La colonne Hôte doit afficher localhost ou 127.0.0.1. Si vous voyez un joker %, cet utilisateur peut se connecter depuis n'importe quelle adresse IP.

Supprimez tous les utilisateurs définis sur % et recréez-les avec localhost comme hôte :

DROP USER 'wpuser'@'%';

CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'YourPassword';

GRANT SELECT, INSERT, UPDATE, DELETE ON your_database_name.* TO 'wpuser'@'localhost';

FLUSH PRIVILEGES;

Utilisateurs d'hébergement mutualisé

Si vous êtes sur un hébergement mutualisé et que vous n'avez pas accès au fichier de configuration MySQL, consultez votre panneau de contrôle à la place. Dans cPanel, recherchez MySQL distant dans la section Bases de données.

Supprimez toutes les adresses IP qui y sont listées. C'est l'équivalent de la fermeture de l'accès à distance au niveau de l'hébergement.

Pour confirmer que l'accès à distance est désactivé, votre utilisateur de base de données WordPress doit afficher localhost comme seul hôte autorisé dans l'écran Comptes d'utilisateurs de phpMyAdmin.

Étape 5 : Protégez votre fichier wp-config.php

Votre fichier wp-config.php contient le nom de votre base de données, votre nom d'utilisateur, votre mot de passe et vos clés d'authentification en texte brut. Si un attaquant peut lire ce fichier, il a tout ce dont il a besoin pour se connecter directement à votre base de données. C'est l'un des premiers fichiers ciblés lors de toute attaque WordPress.

Appliquez les trois protections suivantes ensemble. Chacune d'elles ferme une exposition différente.

1. Déplacez le fichier au-dessus de la racine web

WordPress recherche automatiquement un répertoire au-dessus de la racine s'il ne trouve pas wp-config.php à sa place, vous pouvez donc déplacer le fichier sans modifier aucun paramètre. Si la racine de votre site est /public_html, déplacez wp-config.php vers /home/username/. Utilisez FTP ou le gestionnaire de fichiers de votre hébergeur pour ce faire.

Cela fonctionne sur la plupart des configurations d'hébergement standard, mais certains fournisseurs d'hébergement géré ne le permettent pas. Si votre hébergeur restreint l'accès au-dessus de la racine web, passez aux deux protections suivantes.

2. Bloquez l'accès web via .htaccess

Ajoutez la règle suivante à votre fichier .htaccess, qui se trouve dans le répertoire racine de votre WordPress. Cela indique à Apache de refuser toutes les requêtes du navigateur pour le fichier directement, même si quelqu'un connaît le chemin :

<Files wp-config.php>

order allow,deny

deny from all

</Files>

Si votre hébergeur utilise une configuration Apache plus récente, utilisez plutôt cette version :

<Files "wp-config.php">

Require all denied

</Files>

3. Définissez les permissions du fichier sur 400 ou 440

Les permissions de fichier contrôlent quels utilisateurs sur le serveur peuvent lire, écrire ou exécuter un fichier. Définir wp-config.php sur 400 signifie que seul le propriétaire du fichier peut le lire. Le définir sur 440 étend l'accès en lecture au groupe du serveur également, ce que certaines configurations d'hébergement exigent.

Dans le gestionnaire de fichiers de votre hébergeur, faites un clic droit sur wp-config.php, sélectionnez Changer les permissions et entrez 400. Via FTP, la plupart des clients vous permettent de faire un clic droit sur le fichier et de définir les permissions directement.

Pour confirmer que les trois protections sont en place, essayez d'accéder à votredomain.com/wp-config.php dans un navigateur. Vous devriez obtenir une erreur 403 Forbidden.

Le renforcement de la base de données dans les étapes précédentes réduit considérablement votre surface d'attaque. Mais cela n'élimine pas le risque qu'un plugin vulnérable devienne un point d'entrée pour l'injection SQL.

Lorsque WordPress et MySQL s'exécutent sur le même serveur, les données restent locales et ne traversent jamais un réseau. Mais si votre base de données s'exécute sur un serveur séparé (courant dans les configurations VPS, l'hébergement cloud ou les environnements gérés), ces données voyagent sur une connexion réseau. Sans SSL, elles voyagent en texte brut, y compris les identifiants de connexion et les jetons de session.

Si vous êtes sur un hébergement mutualisé standard avec WordPress et MySQL sur le même serveur, vous pouvez ignorer cette étape. Si vous êtes sur une architecture multi-serveurs ou une configuration cloud où votre base de données s'exécute séparément, ne l'ignorez pas.

Vérifiez d'abord auprès de votre hébergeur

De nombreux fournisseurs d'hébergement géré gèrent automatiquement le SSL pour les connexions de base de données. Kinsta, WP Engine et Cloudways imposent tous des connexions de base de données cryptées au niveau de l'infrastructure. Consultez la documentation de votre hébergeur avant d'apporter des modifications manuelles — vous pourriez déjà être couvert.

Activer le SSL sur le serveur MySQL

Si vous gérez votre propre serveur, ajoutez ce qui suit à votre fichier mysqld.cnf pour configurer les certificats SSL et exiger des connexions cryptées :

[mysqld]

ssl-ca = /path/to/ca.pem

ssl-cert = /path/to/server-cert.pem

ssl-key = /path/to/server-key.pem

require_secure_transport = ON

Redémarrez MySQL après avoir enregistré le fichier.

Dire à WordPress d'utiliser le SSL

Ajoutez la ligne suivante à votre fichier wp-config.php, au-dessus de la ligne qui dit /* C'est tout, arrêtez de modifier ! */ :

define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL);

Cela indique à la connexion de base de données de WordPress d'exiger le SSL lors de la connexion à MySQL.

Pour confirmer que le SSL est actif, vérifiez le journal d'erreurs de votre serveur MySQL après que WordPress ait effectué sa prochaine connexion à la base de données. Vous devriez voir le SSL listé comme actif pour l'utilisateur de l'application.

Étape 7 : Ajouter un pare-feu d'application Web

The database hardening in the previous steps reduces your attack surface significantly. But it doesn’t eliminate the risk of a vulnerable plugin becoming an entry point for SQL injection.

Un pare-feu d'application Web (WAF) se place devant votre site et filtre les requêtes malveillantes avant qu'elles n'atteignent WordPress ou votre base de données.

Pour la sécurité de la base de données, le travail le plus important d'un WAF est de reconnaître les modèles d'injection SQL dans les entrées de formulaire, les paramètres d'URL et les en-têtes de requête, et de les bloquer avant qu'ils ne s'exécutent. Il bloque également les adresses IP et les bots malveillants, réduit les tentatives de connexion par force brute et conserve un journal des requêtes bloquées que vous pouvez examiner si quelque chose semble suspect.

Trois options de WAF fonctionnent bien pour la plupart des sites WordPress :

• Wordfence : S'installe directement en tant que plugin WordPress. Le niveau gratuit comprend un WAF avec une protection de base contre l'injection SQL. Le niveau premium ajoute une intelligence des menaces en temps réel et des mises à jour de règles plus rapides.
• Sucuri : Offre un scanner basé sur un plugin et un WAF au niveau DNS. L'option au niveau DNS achemine tout le trafic via le réseau de Sucuri avant qu'il n'atteigne votre serveur, ce qui offre une protection plus solide mais nécessite un plan payant.
• Cloudflare : Un WAF au niveau DNS avec un niveau gratuit qui couvre le filtrage d'attaques de base. Les plans payants ajoutent des règles plus granulaires et une meilleure couverture pour les attaques au niveau de l'application.

Si vous devez ajuster les règles du pare-feu après la configuration, testez toute modification sur une copie de staging de votre site avant de l'appliquer en production. Une règle mal configurée peut bloquer le trafic légitime : les formulaires de contact, les flux de paiement et les actions d'administration sont des victimes courantes.

Un WAF est une couche complémentaire, pas un remplacement des étapes de renforcement que vous avez déjà effectuées. Considérez-le comme le filtre qui attrape ce qui passe à travers tout le reste.

Étape 8 : Nettoyer les tables d'extensions abandonnées

Lorsque vous désinstallez un plugin dans WordPress, ses tables de base de données sont généralement laissées derrière. WordPress ne les supprime pas automatiquement, et la plupart des plugins ne font pas de nettoyage après eux lors de la désinstallation.

Au fil du temps, ces tables orphelines gonflent votre base de données et créent un risque de sécurité caché : une table d'un plugin présentant une vulnérabilité connue d'injection SQL est toujours exploitable même après la disparition du plugin lui-même.

Pour identifier les tables orphelines, utilisez un plugin comme WP-Optimize ou Advanced Database Cleaner. Les deux analysent votre base de données et signalent les tables qui ne correspondent à aucun plugin actuellement actif.

Installez-en un, lancez une analyse d'optimisation de la base de données, et examinez les résultats avant de supprimer quoi que ce soit.

Vous pouvez également examiner la liste des tables manuellement dans phpMyAdmin. Sélectionnez votre base de données WordPress dans la barre latérale gauche et parcourez la liste des tables. Les tables qui ne correspondent pas à votre $table_prefix actuel ou qui portent le nom d'un plugin que vous n'utilisez plus sont candidates à la suppression.

Cependant, créez d'abord une nouvelle sauvegarde de votre base de données. La suppression d'une table est permanente, et certaines tables qui semblent abandonnées sont toujours activement utilisées.

Soyez particulièrement prudent avec les tables associées à WooCommerce, aux plugins de formulaires comme Gravity Forms ou WPForms, et aux plugins d'adhésion ou LMS. Ceux-ci stockent souvent des enregistrements de transactions, des soumissions de formulaires et des données utilisateur dont vous pourriez avoir besoin même si le plugin n'est plus actif.

Croisez chaque table candidate avec votre liste de plugins actifs avant de la supprimer. Si vous n'êtes pas sûr à quoi appartient une table, recherchez le nom de la table avec le mot « WordPress » pour identifier le plugin qui l'a créée.

Pour supprimer une table orpheline confirmée dans phpMyAdmin, sélectionnez la table, cliquez sur Opérations, et faites défiler vers le bas pour cliquer sur Supprimer la table. Alternativement, exécutez-la via l'onglet SQL :

DROP TABLE old_plugin_table_name;

Pour confirmer que le nettoyage s'est bien déroulé, effectuez un test fonctionnel rapide sur votre site après avoir supprimé les tables. Vérifiez votre page d'accueil, soumettez un formulaire de test si vous en avez un, et déconnectez-vous puis reconnectez-vous.

Étape 9 : Configurer les sauvegardes chiffrées

Les étapes ci-dessus réduisent les chances de subir une attaque réussie sur votre base de données. Cette étape est ce qui vous permet de vous en sortir.

La plupart des gens considèrent les sauvegardes comme un outil de reprise après sinistre. Selon la façon dont vous les créez, elles peuvent également constituer un risque de sécurité.

Un fichier de sauvegarde non chiffré dans un dossier Google Drive est une copie secondaire de votre base de données entière. Toute personne ayant accès à ce compte de stockage peut le télécharger, l'ouvrir et lire chaque enregistrement utilisateur, hachage de mot de passe et commande client sans jamais toucher votre site en direct. Le chiffrement rend ce fichier inutile sans votre clé.

C'est pourquoi je chiffre toujours les sauvegardes avec Duplicator. Ce plugin vous permet d'activer le chiffrement AES-256 sur chaque sauvegarde.

AES-256 est la même norme de chiffrement utilisée par les institutions financières et les systèmes gouvernementaux. Une fois activée, votre archive de sauvegarde est complètement illisible sans mot de passe, même si quelqu'un télécharge le fichier directement depuis votre compte de stockage.

Deux choses à faire avant de sauvegarder : notez ce mot de passe et stockez-le dans un gestionnaire de mots de passe. Si vous le perdez, vos sauvegardes chiffrées deviennent définitivement inaccessibles. Gardez une copie quelque part en dehors de WordPress.

Étape 10 : Planifier les sauvegardes automatiques de la base de données

Une sauvegarde chiffrée ne vous protège que si vous en avez réellement une lorsque quelque chose tourne mal.

Les sauvegardes manuelles échouent en pratique car la vie s'en mêle. Vous vous souvenez d'en lancer une avant une mise à jour majeure, peut-être après une migration, occasionnellement quand quelque chose semble suspect. Ce que vous ne faites pas, c'est en lancer une chaque jour sans faute.

Cet écart est la différence entre un retour arrière propre et un retour arrière désordonné. Si un attaquant crée un compte administrateur non autorisé ou injecte du contenu malveillant aujourd'hui et que vous ne le remarquez pas pendant deux semaines, vous avez besoin d'une sauvegarde datant d'avant cet événement.

Un calendrier quotidien vous donne un point de restauration propre qui n'a jamais plus de 24 heures. Une habitude de sauvegarde manuelle vous donne ce que vous avez exécuté en dernier.

Dans votre tableau de bord WordPress, accédez à Duplicator Pro » Planifier la sauvegarde et cliquez sur Ajouter. Nommez le calendrier de sauvegarde et choisissez un modèle. Par exemple, vous pourriez créer un modèle de sauvegarde de base de données.

Choisissez un emplacement de stockage. Duplicator prend en charge les sauvegardes locales, ainsi que les stockages cloud populaires tels que Duplicator Cloud, Google Drive, Amazon S3 et Google Cloud.

Définissez la fréquence en fonction de l'activité de votre site.

Les sauvegardes quotidiennes de la base de données sont la bonne solution pour tout site qui publie du contenu régulièrement, traite des commandes ou a des comptes utilisateurs actifs. Hebdomadaire convient aux sites statiques ou à faible trafic où la base de données change peu fréquemment.

Étape 11 : Stocker les sauvegardes hors site avec Duplicator Cloud

Une sauvegarde stockée sur le même serveur que votre site n'est pas une vraie sauvegarde. Si votre serveur est compromis, un ransomware chiffre vos fichiers, ou votre hébergeur subit une défaillance catastrophique, vous perdez votre sauvegarde au moment même où vous perdez votre site.

Le stockage hors site est ce qui sépare « J'ai tout perdu » de « J'ai restauré en 20 minutes ».

Duplicator Cloud est l'option de stockage de sauvegarde WordPress la plus simple. Il a été conçu pour les sauvegardes WordPress, s'intègre directement dans Duplicator Pro et ne nécessite aucune authentification API.

Si vous préférez une alternative, Duplicator Pro prend également en charge Google Drive, Amazon S3, Dropbox, OneDrive et tout fournisseur de stockage compatible S3, y compris Cloudflare R2, Backblaze B2 et DigitalOcean Spaces.

Une fois votre stockage connecté, modifiez votre calendrier de sauvegarde et configurez-le pour envoyer automatiquement des copies à votre fournisseur de stockage connecté après chaque exécution.

Conservez au minimum une copie sur votre hébergeur et une copie dans un stockage cloud hors site. Pour les sites critiques ou ceux qui traitent des données clients, une troisième copie téléchargée localement ajoute une couche de protection supplémentaire.

Si vous avez besoin de restaurer, Duplicator Pro peut extraire directement de votre stockage cloud connecté sans retélécharger l'archive sur votre serveur au préalable.

Accédez à Duplicator Pro » Backups. Trouvez une sauvegarde cloud et cliquez sur Restore. C'est plus rapide qu'un téléchargement manuel et fonctionne même si vos copies de sauvegarde locales ont disparu.

Même si vous n'avez pas accès à votre tableau de bord wp-admin, vous pouvez restaurer une sauvegarde cloud. Votre tableau de bord cloud Duplicator vous permet de revenir instantanément à n'importe quelle sauvegarde à distance, même aux sauvegardes de base de données partielles !

Étape 12 : Surveiller les modifications de la base de données avec Activity Log

Le mouvement le plus courant qu'un attaquant effectue après avoir obtenu un accès à la base de données est la création d'un compte administrateur non autorisé. Cela leur donne un moyen persistant de revenir sur votre site, même après que le point d'entrée d'origine soit fermé et nettoyé.

Sans surveillance, ce compte peut rester inactif pendant des semaines. Avec un plugin de journal d'activité, il apparaît dès sa création.

Activity Log enregistre chaque action sur votre site WordPress avec un horodatage et une adresse IP. Vous suivrez sans effort les connexions des utilisateurs, la création de nouveaux comptes, les changements de rôle et les changements de paramètres.

Pour la sécurité de la base de données, les événements les plus importants sont les nouveaux utilisateurs que vous n'avez pas créés, les escalades de rôle où un compte de niveau inférieur obtient soudainement un accès administrateur, et les tentatives de connexion à partir d'adresses IP inconnues.

Activity Log est inclus gratuitement avec Duplicator Elite. Une fois votre plan actif, téléchargez le plugin et installez-le dans WordPress. Il commencera le suivi immédiatement.

Vérifiez le journal régulièrement pour trois choses.

1. Tout nouveau compte utilisateur que vous ne reconnaissez pas.
2. Tout utilisateur existant dont le rôle a été modifié sans votre action.
3. Toute connexion depuis une adresse IP qui ne correspond pas aux emplacements de votre équipe.

L'un de ces éléments peut indiquer une violation active ou un compromis qui s'est produit il y a des jours ou des semaines.

Activity Log vous permet de filtrer le journal par utilisateur, type d'action ou plage de dates et d'exporter les résultats. Ceci est utile à la fois pour les audits de routine et pour la réponse aux incidents, où vous devez identifier exactement quand une modification non autorisée s'est produite.

Étape 13 : Tester la restauration de votre base de données

La plupart des gens découvrent que leur sauvegarde est cassée exactement lorsqu'ils sont sous la plus grande pression pour récupérer rapidement. Un test ne prend que quelques minutes. Une restauration échouée lors d'un incident actif vous coûte beaucoup plus cher.

La fonctionnalité de staging en un clic de Duplicator Pro vous permet de restaurer une sauvegarde vers une URL de staging séparée sans toucher à votre site en direct. Dans Duplicator Pro » Staging, créez un nouveau site de staging.

Sélectionnez une sauvegarde complète récente comme modèle. Choisissez une palette de couleurs d'administrateur unique pour différencier vos sites de staging et en direct.

Une fois que Duplicator a terminé la création de votre site de staging, vous aurez une réplique complète de votre site en direct. C'est un terrain d'essai efficace pour effectuer des restaurations de test.

Téléchargez une sauvegarde sur la page Import Backups de Duplicator. Parcourez le site de staging une fois la restauration terminée.

Vérifiez votre page d'accueil, connectez-vous au tableau de bord WordPress, ouvrez quelques articles et confirmez que les paramètres de votre plugin sont corrects. Si quelque chose manque ou est cassé, vous avez trouvé le problème maintenant au lieu de le découvrir lors d'une véritable récupération.

Pour confirmer que votre test de restauration a réussi, votre site de staging doit se charger proprement avec tout le contenu, les utilisateurs et les paramètres intacts à la date de la sauvegarde.

Dépannage des problèmes de sécurité de la base de données

Même en suivant chaque étape avec soin, des problèmes peuvent survenir. Voici les points de défaillance les plus courants et comment les surmonter.

Votre site devient blanc après avoir modifié le préfixe de table

Ce que vous voyez : Un écran blanc ou une erreur PHP générique immédiatement après avoir modifié le préfixe de table.

Pourquoi cela se produit : La cause la plus fréquente est une référence de table manquante. Certains plugins stockent l'ancien préfixe dans des données PHP sérialisées dans les tables d'options ou d'usermeta. Si une requête SQL brute a mis à jour les noms de table mais a manqué ces références internes, WordPress ne peut pas trouver ce qu'il cherche.

Comment y remédier : Restaurez immédiatement une sauvegarde. C'est précisément la raison pour laquelle cette sauvegarde est non négociable avant de commencer ces étapes de sécurité de la base de données.

Une fois que vous êtes revenu à un état fonctionnel, utilisez un plugin comme All-In-One Security pour effectuer le changement de préfixe à la place. Leurs outils gèrent automatiquement les données sérialisées et sont beaucoup moins susceptibles de laisser des références brisées.

WordPress ne peut pas se connecter à la base de données après avoir modifié wp-config.php

Ce que vous voyez : Un message « Erreur lors de l’établissement de la connexion à la base de données » sur le front-end ou un écran blanc vierge.

Pourquoi cela se produit : Une faute de frappe dans l'une des valeurs d'identification de la base de données est la cause la plus fréquente. Déplacer wp-config.php vers un emplacement que votre serveur ne peut pas trouver est la deuxième cause la plus fréquente. Des autorisations de fichier trop restrictives (comme 000) peuvent également empêcher WordPress de lire le fichier.

Comment y remédier : Connectez-vous via FTP ou le gestionnaire de fichiers et ouvrez directement wp-config.php. Vérifiez que DB_NAME, DB_USER, DB_PASSWORD et DB_HOST sont corrects et correspondent exactement à ce qui se trouve dans votre panneau de contrôle d'hébergement. Si vous avez déplacé le fichier, confirmez qu'il se trouve un répertoire au-dessus de la racine WordPress, pas plus loin. Définissez les autorisations sur 400 ou 440 si elles ont été modifiées.

Un plugin cesse de fonctionner après avoir restreint les privilèges de la base de données

Ce que vous voyez : Un plugin génère une erreur, ne parvient pas à enregistrer les paramètres ou affiche une notification liée à la base de données après avoir terminé l'étape 3.

Pourquoi cela se produit : Certains plugins nécessitent des autorisations CREATE ou ALTER pour installer ou mettre à jour leurs propres tables de base de données. Une fois ces autorisations révoquées, le plugin ne peut pas effectuer les modifications structurelles dont il a besoin.

Comment y remédier : Réaccordez temporairement les autorisations CREATE et ALTER à votre utilisateur de base de données via phpMyAdmin. Mettez à jour ou réinstallez le plugin, laissez-le terminer sa configuration, puis révoquez à nouveau ces autorisations. C'est une partie normale de la maintenance d'une configuration de base de données avec le moins de privilèges.

Rien ne fonctionne : chemin de récupération complet

Si votre site ne répond pas, que votre tableau de bord WordPress est bloqué et que vous ne pouvez pas y accéder par les moyens habituels, utilisez l'une des options de récupération d'urgence de Duplicator.

Pour les sauvegardes stockées dans Duplicator Cloud, vous pouvez les restaurer à distance. Votre site sera de nouveau en ligne sans aucune dépannage supplémentaire.

Avant que les catastrophes ne surviennent, vous pouvez également définir une sauvegarde comme point de récupération dans WordPress. Conservez l'URL de récupération d'urgence dans un endroit sûr.

Si votre site ne fonctionne pas, collez cette URL dans un navigateur Web et suivez les instructions.

Si vous n'avez pas configuré de sauvegardes d'urgence ou de sauvegardes cloud, contactez la ligne de support d'urgence de votre fournisseur d'hébergement. La plupart des hébergeurs gérés conservent leurs propres instantanés au niveau du serveur. Pour les sites sous attaque active avec des logiciels malveillants se propageant en temps réel, Wordfence et Sucuri proposent tous deux des services d'intervention d'urgence payants.

Questions fréquemment posées (FAQ)

Vous avez renforcé votre base de données. Voici comment la maintenir ainsi.

Si vous avez suivi toutes ces étapes, votre base de données est en meilleure forme que la majorité des sites WordPress actuellement en fonctionnement.

Le travail n’est cependant pas terminé. La sécurité de la base de données n’est pas une configuration unique. C’est une pratique de maintenance.

Examinez votre journal d’activité chaque mois et recherchez tout ce qui ne correspond pas à votre propre activité. Testez une restauration chaque trimestre — les connexions de stockage expirent, les mots de passe de chiffrement sont égarés, et la seule façon de savoir si vos sauvegardes sont utilisables est de les utiliser.

Ré-auditez les privilèges de vos utilisateurs de base de données après chaque nouvelle installation de plugin, car certains plugins ré-escaladent les autorisations lors des mises à jour sans que cela soit évident. Et si vous migrez jamais vers un nouvel hébergeur, refaites les étapes 4 et 5 à partir de zéro. Les paramètres d’accès à distance et les autorisations de fichiers ne se reportent pas toujours comme vous pourriez vous y attendre.

Une fois cette configuration terminée, créez une sauvegarde de la base de données uniquement et étiquetez-la clairement comme votre référence post-renforcement. Si vous avez un jour besoin d’enquêter sur une compromission des mois plus tard, cette référence vous donne un point de comparaison clair.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator Pro pour gérer les sauvegardes, les migrations, le staging et la récupération d’urgence. C’est l’outil derrière les archives chiffrées AES-256, le stockage hors site Duplicator Cloud, les restaurations en un clic, la récupération de base de données uniquement et les URL de récupération d’urgence qui vous permettent de revenir même lorsque WordPress lui-même ne se charge pas.

Si ce tutoriel vous a aidé, ces guides méritent également d'être mis en favoris.

• Comment optimiser votre base de données WordPress
• Voici les étapes de réparation de la base de données WordPress que j'ai moi-même suivies (aucun développeur nécessaire)
• Maintenance de la base de données WordPress : Ce qu'il faut faire chaque semaine, chaque mois et chaque trimestre
• WordPress est-il sécurisé ? La vérité révélée
• Comment protéger votre site Web contre les pirates informatiques (Guide ultime de sécurité)
• Comment récupérer un site WordPress piraté (9 conseils d’experts)