Renforcer la sécurité de WordPress : droits, wp-config et .htaccess

Les mises à jour, un mot de passe robuste et l'authentification à deux facteurs constituent la base d'un site WordPress sécurisé. Le durcissement (hardening) vient s'y ajouter : vous configurez le site de sorte qu'une faille ou un compte compromis puisse causer moins de dégâts. Vous découvrirez ici de quels réglages il s'agit et comment les appliquer sur votre hébergement.

Ce qui est déjà fait sur le serveur

Une partie est déjà prise en charge sur nos serveurs. xmlrpc.php est bloqué par défaut (WordPress : impossible d'accéder à xmlrpc.php), les fonctions PHP dangereuses sont désactivées (Sécurité PHP : fonctions désactivées), et un pare-feu pour le trafic web ainsi qu'un scanner de logiciels malveillants sont actifs. Consultez Pare-feu applicatif web et Imunify360 : analyser votre site web à la recherche de logiciels malveillants. Les étapes ci-dessous sont à effectuer vous-même, dans votre propre site.

Vous modifiez tous les fichiers dans DirectAdmin avec le Gestionnaire de fichiers. Les fichiers dont le nom commence par un point, comme .htaccess, ne sont visibles que si vous affichez les fichiers cachés : consultez Afficher et modifier les fichiers cachés comme .htaccess. Faites d'abord une copie de chaque fichier, et placez cette copie en dehors de public_html.

1. Pas de modification du code depuis l'administration

Ouvrez wp-config.php dans domains/example.com/public_html et placez cette ligne au-dessus de la ligne « arrêtez de modifier » (That's all, stop editing!) :

define( 'DISALLOW_FILE_EDIT', true );

Les éditeurs de fichiers de thèmes et d'extensions disparaissent alors de l'administration. Une personne qui prend le contrôle d'un compte administrateur ne pourra donc pas y insérer du code malveillant dans votre thème en quelques clics. L'installation et la mise à jour des extensions continuent de fonctionner normalement. Dans le même fichier, réglez WP_DEBUG sur false, afin que les messages d'erreur ne s'affichent jamais à l'écran des visiteurs.

2. Pas de PHP dans le dossier uploads

Le dossier wp-content/uploads est destiné aux images et aux documents, pas au PHP. Un intrus capable de téléverser un fichier via une faille essaiera justement d'y déposer un fichier PHP puis de l'appeler. Créez dans wp-content/uploads un fichier .htaccess contenant :

<Files *.php>
Require all denied
</Files>

Vérifiez ensuite que votre site, vos formulaires et votre médiathèque fonctionnent toujours.

3. Pas de liste des dossiers

Lorsqu'un dossier ne contient ni index.php ni index.html, un serveur web peut afficher la liste de tous ses fichiers. Ajoutez en haut du fichier .htaccess dans public_html :

Options -Indexes

Pour tester, appelez un dossier sans fichier index, par exemple https://example.com/wp-content/uploads/. Vous devriez voir une page d'erreur (403 ou 404), et non une liste.

4. Permissions des fichiers et des dossiers

N'utilisez jamais 777 : tout le monde sur le serveur pourrait alors écrire dans ce dossier. Si un tutoriel affirme que c'est nécessaire pour que le téléversement fonctionne, la cause se trouve ailleurs. Pour modifier les permissions, consultez Permissions des fichiers et des dossiers (chmod).

5. Pas de restes dans le dossier web

Tout ce qui se trouve dans public_html est accessible via le web. Faites donc le ménage :

• les copies de wp-config.php, comme wp-config.php.bak ou wp-config.old. Elles contiennent votre mot de passe de base de données et sont envoyées en texte brut ;
• les sauvegardes comme backup.zip ou database.sql ;
• un dossier .git laissé par un développeur ;
• wp-content/debug.log ;
• les fichiers de test comme info.php contenant phpinfo().

Pour rendre un fichier précis inaccessible, consultez Bloquer des fichiers via .htaccess.

6. En-têtes et connexion

• Les en-têtes de sécurité indiquent au navigateur comment traiter votre site. Consultez HSTS et en-têtes de sécurité pour votre site web.
• La page de connexion peut être limitée à votre propre adresse IP grâce à Sécuriser wp-login.php de WordPress.
• L'authentification à deux facteurs pour les administrateurs : consultez Configurer l'authentification à deux facteurs pour WordPress.

Masquer la version de WordPress relève du rangement, pas de la sécurité : les programmes d'attaque testent simplement la faille. Seule la mise à jour comble la faille.

Et une extension de sécurité ?

Une extension de sécurité regroupe souvent un pare-feu, un scanner et une protection de la connexion. Un pare-feu intégré à une extension ne fonctionne qu'une fois WordPress lancé ; le pare-feu du serveur bloque les requêtes plus tôt. Une extension est donc un complément, surtout pour l'authentification à deux facteurs et la limitation des tentatives de connexion. N'en utilisez qu'une seule au maximum : deux extensions de sécurité installées ensemble entrent souvent en conflit.

Pour aller plus loin

• Hardening WordPress (developer.wordpress.org, en anglais)

Envie d'en apprendre davantage ? Suivez le cours WordPress gratuit, leçon 7.4 Durcir le site : permissions, en-têtes et extensions de sécurité.