Règles de sécurité .htaccess WordPress qui servent vraiment

La plupart de ce qu’on vend comme « sécurité .htaccess WordPress » n’est que du remplissage. Les règles qui changent réellement votre surface d’attaque sont courtes : bloquer l’exécution de PHP dans wp-content/uploads, refuser l’accès direct à wp-config.php et désactiver l’affichage du contenu des répertoires. Les plus populaires — bloquer xmlrpc.php « pour stopper le brute force », masquer votre version de WordPress, coller une liste de 200 lignes de user-agents de mauvais bots — vont du marginal au pur théâtre. Voici lesquelles sont lesquelles, et pourquoi.

Un point à régler d’abord : .htaccess n’a d’effet que sur Apache (et LiteSpeed, qui le lit aussi). Sur nginx, il est totalement ignoré — le fichier reste là pendant que vous vous croyez protégé. Si votre hébergeur tourne sous nginx, rien de tout cela ne s’applique et il vous faut des blocs server/location à la place. Vérifiez avec curl -I https://votresite.com et regardez l’en-tête Server: avant de passer une heure à éditer un fichier que le serveur ne lit jamais.

La règle qui compte vraiment : pas de PHP dans /uploads

C’est celle qui vaut le coup. wp-content/uploads est accessible en écriture par tout le monde, par conception — chaque média envoyé, chaque plugin qui enregistre un fichier, écrit là. Si un attaquant parvient à y déposer un fichier .php (via un gestionnaire d’upload vulnérable, un champ image qui ne valide pas le type MIME, un plugin compromis), la différence entre une simple gêne et une compromission complète par exécution de code à distance tient à une seule chose : est-ce que le serveur va exécuter ce fichier quand on le demande. Refusez l’exécution, et la charge envoyée n’est plus qu’un fichier inerte posé sur le disque.

Ajoutez ceci dans wp-content/uploads/.htaccess (créez le fichier s’il n’existe pas) :

<FilesMatch "\.php$">
    Require all denied
</FilesMatch>

C’est la syntaxe d’Apache 2.4. Sur l’ancienne 2.2, l’équivalent est Order Deny,Allow / Deny from all. Mélanger les deux dialectes dans un même fichier est la cause la plus fréquente d’un 500 Internal Server Error soudain après « durcissement » — si tout le site meurt à l’instant où vous enregistrez, c’est presque toujours la raison. Vérifiez votre version avec apachectl -v.

Protéger wp-config.php

wp-config.php contient les identifiants de votre base de données et vos clés d’authentification. Tant que PHP tourne, une requête directe vers ce fichier renvoie une page blanche — PHP exécute le fichier au lieu de l’afficher. Le risque, c’est le cas de défaillance : si PHP plante un jour, est mal configuré pendant une migration, ou si le gestionnaire est désactivé, Apache sert le fichier en texte brut et livre votre mot de passe de base de données à quiconque le demande. Refuser l’accès est une assurance bon marché contre un mauvais quart d’heure :

<Files wp-config.php>
    Require all denied
</Files>

Désactiver l’affichage du contenu des répertoires

Si quelqu’un visite un dossier sans index.php et qu’Apache a Options +Indexes activé, il en liste le contenu — chaque fichier de sauvegarde, chaque dump SQL oublié qui traîne. Désactivez-le sur tout le site :

Options -Indexes

Gravité faible, mais réel, et ça ne coûte rien.

Voilà la liste de base, honnête. Vous pouvez assembler ces règles — avec la bonne syntaxe 2.4 vs 2.2 pour ne pas mettre votre site en 500 — grâce au générateur de .htaccess WordPress, plutôt que de copier-coller un message de forum écrit pour la mauvaise version d’Apache.

Ce qu’il ne faut PAS faire

Bloquer xmlrpc.php « pour se protéger du brute force ». C’est le gros classique que tout le monde répète, et c’est faux tel quel. Oui, la méthode system.multicall de XML-RPC a historiquement permis à un attaquant de regrouper de nombreuses tentatives de connexion dans une seule requête — une vraie amplification. Mais le vecteur de brute force largement le plus courant, ce sont de simples requêtes POST vers wp-login.php, et bloquer xmlrpc.php n’y change rien. Le brute force se contre par la limitation de débit, des mots de passe forts et la 2FA — pas en tuant un endpoint. Il existe une vraie raison de désactiver XML-RPC : sa fonction de pingback peut être détournée pour de la réflexion DDoS, donc si vous n’utilisez pas Jetpack, l’application mobile ou les pingbacks, le fermer réduit votre surface d’attaque. Ne vous racontez simplement pas que c’est votre défense contre le brute force, parce que ce n’en est pas une.

Masquer votre version de WordPress / retirer la balise generator. Supprimer readme.html et la balise <meta name="generator"> donne l’impression de durcir. Un attaquant identifie votre version en quelques secondes à partir des chaînes de requête des ressources mises en file, du balisage de l’éditeur de blocs et d’une douzaine d’autres indices. Vous ne cachez rien ; vous vous donnez juste l’impression d’être occupé.

Énormes listes de blocage de user-agents et de referrers de mauvais bots. Un user-agent, c’est un simple en-tête HTTP falsifiable. Ces listes sont périmées le jour où vous les collez, elles ne bloquent rien de compétent, et Apache évalue chaque regex à chaque requête — vous payez une vraie taxe de performance pour zéro sécurité. Oubliez-les.

Verrouiller wp-login.php par IP. Génial jusqu’à ce que votre FAI change votre adresse et que vous soyez enfermé dehors de votre propre admin. Viable uniquement avec une IP réellement fixe.

Redirections contre l’énumération d’auteurs (?author=1). La réécriture .htaccess que les gens collent pour ça est incomplète à elle seule — l’endpoint REST /wp-json/wp/v2/users liste toujours les identifiants. Bloquer un chemin en laissant l’autre ouvert, c’est du théâtre.

Toujours bloqué ?

Si une règle met le site en 500, c’est de la syntaxe — retirez le dernier bloc ajouté et rechargez ; ça l’isole immédiatement. Si une règle semble ne rien faire, vérifiez que vous êtes bien sous Apache et que AllowOverride est activé pour le répertoire (beaucoup d’hébergeurs managés le restreignent). Construisez le fichier à partir d’un modèle éprouvé avec le générateur de .htaccess, gardez les trois règles qui comptent, et laissez tomber le reste.