Protection Site WordPress : Règles de Sécurité pour le .htaccess

Quand on parle de sécurité pour un site WordPress, on pense souvent aux plugins, aux mots de passe, à la mise à jour du cœur. Tout cela est réel, mais il existe un autre levier souvent sous-utilisé, le fichier .htaccess. Sur les serveurs Apache, c’est lui qui permet d’ajuster la manière dont le serveur répond aux requêtes avant même que WordPress ne s’exécute.

Le piège, c’est que .htaccess peut aussi casser le site si on copie des recettes au hasard. Une règle trop agressive, un ordre de directives mal compris, ou une directive qui ne correspond pas à votre configuration (multisite, sous-dossiers, HTTPS mal géré) et vous vous retrouvez avec des pages 404 ou un accès admin “intermittent”. Mon approche est simple: partir des objectifs, appliquer des protections qui ont du bon sens, mesurer l’impact, puis verrouiller petit à petit.

Comprendre le rôle de .htaccess dans WordPress

Sur Apache, .htaccess est lu à la demande pour le répertoire où il est placé (et ses sous-répertoires). Son contenu est une suite de directives, souvent liées à la redirection, au contrôle d’accès, au filtrage d’URL, et parfois à la compression ou au cache. En sécurité, l’intérêt est que vous pouvez:

refuser des chemins évidents avant qu’ils atteignent WordPress, limiter l’exposition de certains fichiers, réduire la surface d’attaque liée à des endpoints fréquents, empêcher des comportements “bruyants” (scans simples, tentatives de navigation inutile).

Important aussi: WordPress lui-même dépose généralement des règles dans .htaccess, notamment pour la réécriture d’URL (les “permalinks”). Cela veut dire qu’un .htaccess sécurité doit cohabiter avec celui de WordPress. Dans la pratique, on ajoute des blocs autour du bloc WordPress, ou on insère des règles au bon endroit, sans toucher à la logique principale de réécriture.

Avant de modifier: les garde-fous qui évitent les crises

Avant d’écrire la moindre règle, j’insiste sur quelques vérifications simples. Elles ne sont pas glamour, mais elles sauvent du temps.

D’abord, faites une sauvegarde du fichier .htaccess actuel. Ensuite, vérifiez que vous savez où il se situe. Sur un WordPress classique en racine, c’est généralement dans le dossier du site. En sous-dossier, c’est dans le dossier du WordPress.

Enfin, gardez en tête le contexte serveur. Les règles .htaccess fonctionnent surtout sur Apache. Sur Nginx, ce mécanisme n’existe pas sous la même forme. Sur certains hébergements, les directives peuvent être partiellement désactivées côté configuration du serveur. Autrement dit, une règle “valable” sur papier peut ne pas s’appliquer.

Si vous avez des accès FTP, un panneau d’hébergement, ou un SFTP, vous pouvez faire un test en appliquant une modification, puis en vérifiant:

l’accès aux pages publiques, l’accès wp-admin, l’accès aux médias, la résolution des permaliens (exemple: une URL “/categorie/article” doit continuer de fonctionner).

Ces contrôles sont concrets, et surtout rapides.

Un mini plan d’action (sans se tromper de cible)

Voici un ordre de travail que j’utilise pour éviter les effets de bord:

Sauvegarder le .htaccess actuel, puis créer un “versionnement” si possible Identifier la présence d’un bloc WordPress (souvent marqué par “BEGIN WordPress” et “END WordPress”) Tester l’accès aux permaliens et à wp-admin après chaque changement notable Éviter les règles qui dépendent d’un champ (comme un header) que vous ne maîtrisez pas Noter les erreurs 403 et 404: si vous les voyez trop, reculez et ajustez

La première couche: limiter l’exposition de fichiers et de répertoires

La plupart des tentatives de piratage commencent par l’envoi de requêtes “typées”. Elles cherchent des fichiers par noms. Elles ne “négocient” pas, elles scannent.

Sur WordPress, certains fichiers et dossiers sont des cibles évidentes: dossiers de configuration, sauvegardes, fichiers systèmes, répertoires inutiles pour un navigateur. Une première bonne pratique consiste à bloquer l’accès web aux fichiers qui n’ont aucune raison d’être servis, en particulier ceux qui finissent par exister après des manipulations (fichiers de sauvegarde) ou ceux qui sont spécifiques à l’administration serveur.

Un bloc classique que je place avant le bloc WordPress (ou au minimum sans casser la réécriture) ressemble à ceci:

# Bloquer l’accès à certains fichiers sensibles Require all denied # Bloquer l’accès aux fichiers .htaccess et .htpasswd Require all denied # Empêcher l’accès au contenu des dossiers de configuration courants (si présents) RedirectMatch 403 ^/(\.git|\.svn|\.hg)/

Quelques remarques issues de l’expérience: vous ne voulez pas bloquer des extensions que votre site utilise vraiment (par exemple, si vous servez des archives en téléchargement, .zip peut exister dans vos médias). Dans ce cas, adaptez le pattern ou ajoutez une exception par répertoire (ce qui doit rester prudent).

Notez aussi la directive Require all denied. Elle correspond à des environnements récents basés sur mod_authz_core. Sur certains serveurs plus anciens, on utilisait encore Order deny,allow et Deny from all. Si vous ne savez pas quel mode est actif, restez sur Require all denied, car c’est généralement compatible dans les configurations modernes. Sinon, testez et observez le résultat.

Filtrer l’accès direct aux scripts PHP hors logique applicative

Dans une installation WordPress, les scripts PHP ne sont généralement pas censés être appelés directement via des URLs “internes” comme /index.php ou /wp-config.php (au sens “fichiers à exécuter par le client”). Les serveurs et la configuration WordPress gèrent la route via l’URL “propre”.

Cela dit, certaines tentatives utilisent des chemins de type wp-login.php, xmlrpc.php, ou des patterns “camouflés”. L’objectif n’est pas de faire disparaître tout le bruit, mais de réduire les appels inutiles.

Sur .htaccess, on peut restreindre certains endpoints sensibles, par exemple:

wp-config.php et les fichiers de configuration wp-includes et des éléments internes dans certains cas xmlrpc.php selon votre besoin

Voici un exemple ciblé pour WordPress:

# Empêcher l'accès aux fichiers de configuration Require all denied # Empêcher l'accès au dossier wp-includes # (à utiliser avec prudence, certains thèmes/plugins peuvent y accéder) RewriteEngine On RewriteRule ^wp-includes/ - [F,L]

Le bloc “wp-includes” est une règle qui divise. Sur le papier, c’est “interne”. Mais dans la réalité, WordPress sert des ressources depuis wp-includes (scripts, styles, images selon configuration). Si vous bloquez tout, votre site peut casser, parfois sans message explicite au début, juste des fonctionnalités qui ne se chargent plus. Si vous souhaitez vraiment appliquer cette logique, faites-le uniquement avec une approche plus fine (par type de fichier ou dossiers précis) et testez sur plusieurs pages.

La règle la plus sûre reste le blocage des fichiers manifestement sensibles comme wp-config.php, et la réduction d’accès à des endpoints connus pour être malmenés, comme xmlrpc.php.

Réduire l’attaque via xmlrpc.php (choix fonctionnel)

xmlrpc.php est un point qui revient souvent dans les tentatives d’exploitation et les abus liés aux authentifications à distance. Il sert à des fonctionnalités comme la publication via certains clients et certaines intégrations.

Si vous n’utilisez pas XML-RPC, le fermer au niveau Apache est une protection efficace. Si vous l’utilisez, vous ne pouvez pas juste le “kill” sans réfléchir.

Un bloc possible:

# Désactiver xmlrpc.php si non utilisé Require all denied

Je l’ai vu sauver des jours entiers de logs pollués sur des sites vitrines qui n’ont pas de clients de publication externes. Par contre, sur un site qui dépend d’outils spécifiques, ça casse des flux. Avant de déployer, vérifiez votre usage réel. Une simple recherche dans l’historique d’intégrations ou dans les plugins peut déjà indiquer si XML-RPC est nécessaire.

Protéger wp-admin et la zone d’administration sans se tirer une balle dans le pied

Restreindre l’accès à wp-admin est tentant. Souvent, on veut limiter à son IP, à un VPN, ou à une plage d’adresses. .htaccess peut le faire, mais c’est une décision d’architecture. Si vos équipes utilisent des connexions mobiles, des horaires variables, ou des proxys, vous risquez de bloquer des gens légitimement.

Quand vous pouvez identifier une plage stable (par exemple IP d’entreprise), c’est une excellente couche. Le principe est de créer une règle d’accès par IP, et de garder WordPress fonctionnel.

Exemple de contrôle d’accès par IP (à adapter):

# Restriction d'accès wp-admin par IP (exemple) Require ip 203.0.113.10 203.0.113.20

Deux points importants:

Remplacez le chemin par le bon chemin serveur. Une erreur de chemin dans peut rendre la règle inopérante ou produire des 500. Listez peu d’IPs au départ, testez. Et prévoyez un “accès de secours” si vous coupez votre propre accès admin.

Dans beaucoup de cas, si vous n’êtes pas sûr, privilégiez des solutions plus souples via le serveur ou un pare-feu applicatif. Mais si vous êtes en environnement simple et maîtrisé, .htaccess peut faire le travail.

Bloquer des schémas d’URL courants (sans bloquer WordPress lui-même)

Un autre https://gardewp.fr/securite-wordpress/ levier, c’est le filtrage par pattern sur des URLs qui servent souvent à “forcer” des routes inexistantes ou à tester des failles connues.

Un piège courant: bloquer des “mots” dans l’URL et empêcher des pages légitimes. Par exemple, admin dans l’URL peut exister dans un slug de page. login peut exister dans un article. Ces collisions rendent des filtres trop naïfs risqués.

C’est pour cela que je préfère des règles qui ciblent des fichiers ou des endpoints exacts, ou des comportements clairement malveillants.

Par exemple, beaucoup de scanners cherchent des fichiers de type wp-sitemap.xml ou testent des endpoints de thème. Cela ne veut pas dire que ce sont des attaques, juste qu’ils explorent.

Si vous voulez bloquer des endpoints précis, par exemple:

wp-sitemap.xml n’est pas “dangereux”, mais si vous ne l’utilisez pas, vous pouvez le laisser. xmlrpc.php est un bon candidat comme vu plus haut. Certains fichiers de type .env sont des candidats très fréquents en essais génériques.

Vous pouvez bloquer .env et fichiers “d’environnement” que WordPress ne devrait pas servir:

# Bloquer les fichiers d'environnement et secrets par essais courants Require all denied

Ce bloc est volontairement basé sur des noms précis, pour limiter le risque de faux positifs. Si vous avez des fichiers similaires, adaptez.

Forcer HTTPS, gérer les redirections proprement

La sécurité passe aussi par la cohérence: un site qui oscille entre HTTP et HTTPS ouvre la porte à des erreurs de cookies, à des redirections inattendues, et à des sessions moins fiables.

Si votre hébergement gère déjà HTTPS au niveau proxy ou en configuration serveur, vous n’avez peut-être pas besoin de redirections .htaccess. Mais si vous en avez besoin, vous pouvez forcer:

RewriteEngine On RewriteCond %HTTPS !=on RewriteRule ^ https://%HTTP_HOST%REQUEST_URI [L,R=301]

Cela évite aussi des variantes d’accès. Sur certains environnements, surtout derrière un load balancer, il faut tenir compte de headers comme X-Forwarded-Proto. En .htaccess, ce n’est pas toujours fiable selon la configuration. Mon conseil est de valider d’abord, en testant depuis votre réseau habituel et, si possible, depuis un autre type de connexion.

Si vous voyez des boucles de redirection, stoppez. Les redirections mal paramétrées sont une cause fréquente de “site inaccessible”.

Garder WordPress performant: quelques choix pragmatiques

La sécurité ne doit pas rendre le site lent. Chaque directive ajoute parfois une étape de traitement. .htaccess est aussi lue à la volée, ce qui a un coût, même si sur des serveurs modernes le sujet est souvent moins dramatique qu’avant.

Ce que je recommande dans la pratique:

limiter les règles au strict nécessaire, éviter les regex gigantesques, ne pas multiplier les blocs sans raison, conserver le bloc WordPress tel quel, et n’ajouter que des protections autour.

Si vous avez un trafic important, la solution idéale est souvent de déplacer certaines règles hors .htaccess vers la configuration serveur. Mais si vous êtes sur un hébergement mutualisé qui ne permet pas, le .htaccess reste votre levier.

Journaliser et surveiller, pas seulement “verrouiller”

Une règle qui bloque correctement se traduit par des codes HTTP: souvent 403. Sans logs, vous ne savez pas si la règle aide, ni si elle bloque des utilisateurs légitimes. Les métriques d’erreur servent d’interface de réalité.

Je fais généralement deux observations simples:

si le nombre de 403 grimpe après déploiement, est-ce que les utilisateurs se plaignent? (par exemple, pages blanches ou erreurs à la connexion) si les 404 augmentent, est-ce que ce sont des erreurs de permaliens, ou des essais de navigation aléatoires?

Sur un site WordPress bien configuré, les 404 “propres” ne devraient pas exploser. Une hausse brutale peut indiquer une règle de réécriture cassée, souvent en touchant au bloc WordPress.

Composer un .htaccess “sécurisé” sans tout casser

La meilleure stratégie que j’ai trouvée consiste à assembler des blocs par objectifs. On protège ce qui doit l’être, puis on valide, puis on ajoute.

Voici une séquence réaliste pour un WordPress standard (racine, Apache, permaliens actifs). Ce bloc est volontairement “modéré”, pour éviter des casseroles:

Conserver le bloc WordPress de réécriture Ajouter des blocages de fichiers manifestement sensibles Fermer xmlrpc.php si non utilisé Appliquer éventuellement une restriction d’accès à wp-admin si vous maîtrisez vos IP Forcer HTTPS si nécessaire

Pour les vérifications après ajout, je m’appuie sur une checklist courte:

ouvrir 3 pages publiques avec des permaliens différents vérifier que wp-admin charge et que la connexion fonctionne tester le chargement d’un média (image, fichier PDF ou autre) vérifier les pages de formulaire (contact, login) si elles existent relire les logs d’erreur et d’accès pour repérer des 403 anormaux

Cette méthode est moins “spectaculaire” que des configs prêtes à copier, mais elle évite le scénario classique où tout semble aller pendant une journée, puis qu’un plugin important ne fonctionne plus.

Cas particuliers: multisite, sous-dossiers, et permaliens bizarres

Dès que vous sortez du WordPress “standard”, les règles .htaccess doivent évoluer. Multisite, par exemple, modifie souvent les chemins et l’accès aux répertoires. Une règle qui cible wp-admin avec un chemin absolu peut ne plus matcher si le WordPress n’est pas à l’emplacement prévu.

Pour les installations en sous-dossier, certains filtres de répertoire comme peuvent ne pas s’appliquer si vous mettez .htaccess à un autre niveau. Dans ce cas, je préfère des règles qui ciblent des chemins relatifs à l’URL, via RewriteRule, plutôt que de dépendre de chemins disque, sauf si vous êtes certain de la structure.

Autre cas: les permaliens. Si votre WordPress utilise une structure “Plain” (pas de réécriture), les règles de WordPress dans .htaccess peuvent différer. Supprimer ou déplacer le bloc WordPress par erreur vous laisse avec des liens cassés.

Mon réflexe est toujours le même: ne jamais “réécrire” le bloc WordPress sans comprendre ce que vous faites. On ajuste autour.

Ce qu’il vaut mieux éviter, même si c’est populaire

Sur les forums, on voit beaucoup de règles qui bloquent “tout” pour sécuriser vite. Certaines sont utiles dans des environnements dédiés. Sur WordPress, elles peuvent devenir une source de bugs.

Je vous déconseille notamment:

de bloquer wp-content en entier (les thèmes, plugins et médias en dépendent), de bloquer admin-ajax.php si votre site l’utilise pour les formulaires et interactions (AJAX), de bloquer trop d’extensions de fichiers qui sont légitimes pour vos téléchargements, de remplacer la partie de WordPress sur la réécriture sans comprendre.

Le but n’est pas d’être parano, c’est d’être précis.

Une touche finale: vérifier que vos règles se combinent bien à l’existant

La réalité des hébergements, c’est que le .htaccess n’est pas toujours vierge. Il peut déjà contenir:

des règles de compression, des règles de cache, des redirections imposées par le provider, des réglages de sécurité ajoutés par un plugin.

Avant d’ajouter une règle, lisez le fichier en entier. Si vous voyez des RewriteEngine On et des règles multiples, l’ordre peut compter. Un bloc trop haut peut court-circuiter un bloc plus bas. En sécurité, l’ordre peut aussi vous piéger, car vous pouvez bloquer un fichier nécessaire, puis constater “ça ne marche plus”, sans savoir quelle ligne est responsable.

Quand je corrige un .htaccess sur un site déjà chargé, j’ai tendance à introduire les règles une par une, pas en “gros coup”. Chaque petite modification apporte une cause claire et un diagnostic facile.

.htaccess ne remplace pas le reste, mais il complète bien la protection site WordPress

Le mot clé “protection site WordPress” revient souvent parce que la sécurité est un ensemble. Le .htaccess apporte une couche d’arrêt précoce, avant que WordPress n’analyse la requête. Mais un bon dispositif reste global: mises à jour à jour, utilisateurs avec des rôles cohérents, mots de passe solides, et plugins choisis.

Le meilleur signe que vos règles .htaccess sont “justes”, c’est qu’elles réduisent le bruit sans casser le fonctionnement. Quand c’est le cas, vous gagnez du temps, moins de tentatives inutiles, et une surface d’attaque un peu plus sèche.

Si vous voulez, vous pouvez me partager votre configuration générale (WordPress en racine ou sous-dossier, Apache ou autre, usage de xmlrpc.php, présence d’un bloc WordPress dans le .htaccess, et votre objectif principal: limiter le spam, bloquer les fichiers sensibles, ou restreindre l’accès admin). Je pourrai alors vous proposer un bloc de règles plus adapté, sans prendre de risques inutiles.