Quand on parle de durcissement WordPress, on imagine souvent des plugins de sécurité, des durées de rotation de mots de passe, ou des reverse proxies bien cadrés. Tout ça est utile. Mais il existe une couche plus immédiate, plus “proche du serveur”, qui agit avant même que WordPress ne décide quoi que ce soit. Cette couche, c’est Apache (ou un serveur compatible) et, dans beaucoup d’installations, le fichier .htaccess.
Utilisé correctement, .htaccess permet de limiter certaines catégories d’accès, de réduire l’exposition d’informations et de rendre plus coûteuse la vie des scripts automatisés. Utilisé sans discernement, il peut casser une partie du site, déclencher des erreurs 500, ou empêcher des fonctionnalités légitimes (REST API, téléchargements, formulaires, caches, ou même certains thèmes et plugins).
L’objectif ici est simple: poser des règles de sécurité réalistes, compréhensibles et testables, adaptées à WordPress, avec des garde-fous.
Ce que .htaccess peut (et ne peut pas) faire
.htaccess est un mécanisme de configuration “par répertoire”. Concrètement, quand Apache reçoit une requête, il recherche si un .htaccess existe dans le chemin demandé, puis applique les directives autorisées. C’est très pratique sur du mutualisé ou quand vous n’avez pas accès à la configuration globale.
Mais il faut garder deux limites en tête:
1) .htaccess ne “remplace” pas la sécurité applicative. Il ne va pas valider des droits, ni corriger une faille dans un plugin, ni empêcher un compte compromis. Il rend seulement certaines choses plus difficiles.
2) selon l’hébergement, toutes les directives ne sont pas disponibles. Certaines restrictions peuvent échouer silencieusement ou produire des logs, et vous ne verrez pas forcément tout de suite ce qui a été ignoré.
Dans la pratique, la meilleure façon de raisonner consiste à traiter chaque règle comme une hypothèse à valider: “est-ce que ça améliore la sécurité sans casser le site ?”
Avant de modifier: vérifier les conditions de fonctionnement
Sur WordPress, la plupart des sites ont déjà un .htaccess structuré autour des permaliens. Les règles existantes ressemblent souvent à des blocs RewriteRule qui dirigent tout vers index.php. Si vous ajoutez une règle trop agressive au mauvais endroit, vous aurez des redirections en boucle ou des 404.
Avant de toucher quoi que ce soit, vérifiez trois choses:
- l’emplacement exact du .htaccess (à la racine du WordPress, pas dans un sous-répertoire au hasard) la présence de règles WordPress pour les permaliens l’accès aux logs Apache (au minimum error.log, idéalement aussi access.log)
Une anecdote fréquente côté maintenance: un propriétaire de site mutualisé modifie .htaccess pour “bloquer des dossiers sensibles”. Deux heures plus tard, plus d’images chargent, car l’hébergeur sert certains assets via un chemin qui ressemble au dossier bloqué. Sans logs, on perd du temps à deviner.
La méthode qui évite les mauvaises surprises
Je recommande un protocole simple, qui a l’avantage de limiter le risque, même quand on est pressé:
Sauvegarder le fichier actuel .htaccess. Ajouter une règle à la fois. Tester sur un navigateur réel, puis avec un outil de vérification HTTP (head ou simple requête) si vous en avez l’habitude. Si quelque chose casse, revenir à l’état précédent, puis isoler la modification incriminée.Cette discipline peut paraître lente, mais sur un durcissement WordPress, les gains viennent surtout de la précision.
Réduire l’exposition: masquer des fichiers et répertoires “cibles”
Les tentatives d’exploration automatisées visent souvent des chemins connus: fichiers de configuration, traces, archives, ou répertoires oubliés. Sans faire croire que vous êtes “inexploitable”, vous pouvez réduire une partie du bruit.
Dans .htaccess, la logique consiste généralement à retourner 404 plutôt que 403. Les deux codes ne sont pas identiques pour les robots: le 404 est souvent “moins bavard”. Cela ne change pas la sécurité intrinsèque d’un mot de passe, mais ça diminue l’information disponible sur votre structure.
Voici un premier paquet de règles prudentes, à placer dans votre .htaccess avec attention, idéalement avant les règles WordPress de réécriture si vous utilisez RewriteRule existantes.
# Réponses plus silencieuses pour certains chemins Require all denied # Bloquer l'accès direct aux fichiers de configuration courants Require all denied # Parfois utile sur WordPress, selon le contexte d’hébergement Options -IndexesPoints importants:
- Options -Indexes évite l’affichage de la liste de répertoires si un dossier ne contient pas d’index. Ce n’est pas une barrière contre une vulnérabilité, mais ça empêche un mode “navigation” utile aux explorateurs. Les motifs de fichiers sensibles doivent être calibrés. Bloquer toutes les archives peut gêner un usage légitime (par exemple des téléchargements gérés “à la main”, ou des backups déposés par un processus interne que vous oubliez).
C’est là que le “jugement” compte: un bloc de sécurité parfait sur papier doit être cohérent avec votre workflow.
Protéger l’accès aux zones WordPress exposées (sans casser le site)
WordPress expose plusieurs endpoints. Certains sont publics par nature, d’autres doivent rester accessibles pour un usage normal. La sécurité vient surtout de la réduction du bruteforce, et de la limitation de ce qui est tenté sans intention légitime.
Deux zones reviennent souvent dans les demandes de durcissement:
- l’accès au fichier de login (wp-login.php) les endpoints XML-RPC (xmlrpc.php), souvent associés à des attaques de bruteforce
XML-RPC: utile ou optionnel ?
Beaucoup de sites n’ont pas besoin d’utiliser XML-RPC (par exemple pour des applications tierces, certains usages d’édition distante, ou des intégrations spécifiques). Si vous n’en avez pas l’usage, réduire son exposition est un levier fort.
Sur .htaccess, on peut choisir une approche “bancale mais efficace”: renvoyer 404 ou 403, ou même désactiver carrément. Sur certains hébergements, une désactivation via .htaccess peut être plus simple que côté WordPress.
Exemple prudence, qui rend l’end-point indisponible:
Require all deniedTrade-off concret: si vous utilisez une application externe ou un plugin qui s’appuie sur XML-RPC, vous allez casser la fonctionnalité. Avant d’ajouter la règle, examinez vos usages. Une manière simple consiste à faire un audit rapide des plugins et à vérifier les paramètres d’outils d’édition distante, mais selon les environnements, il faut parfois simplement confirmer avec l’équipe qui gère le contenu.
wp-login.php: bloquer les plus évidents, pas tout
Pour le login, un blocage global via .htaccess peut être trop radical, car certains rôles et certaines redirections peuvent être nécessaires. La meilleure approche dépend de ce que vous avez déjà en place: WAF, rate limiting au niveau serveur, ou filtrage par IP.
Dans .htaccess seul, sans modules additionnels, vous pouvez au minimum restreindre l’accès à certaines IP connues, ou filtrer des comportements sans toucher les requêtes légitimes. Mais faire du “vrai” antiforce brut nécessite souvent des capacités qui dépassent .htaccess (rate limiting au niveau serveur, ou module dédié).
C’est aussi pour ça que je conseille une approche graduée: on commence par XML-RPC si c’est optionnel, puis on affine sur le login avec des restrictions d’accès uniquement quand elles sont cohérentes.
Bloquer des motifs d’exploration courants, avec parcimonie
Les attaquants automatisent souvent des requêtes qui ressemblent à des essais de traversal, d’accès à des scripts, ou de consommation de ressources. Vous pouvez créer des règles qui renvoient 404 pour certains patterns, par exemple quand l’URL contient des segments connus.
En pratique, je préfère viser des motifs très spécifiques pour éviter les faux positifs. WordPress sert des chemins variés (thèmes, plugins, images, assets, requêtes API). Une règle trop large peut casser.
Voici un exemple qui bloque certains schémas d’accès souvent vus en scans. Ajustez aux logs de votre serveur, car c’est là que vous gagnerez en précision.
RewriteEngine On # Bloquer certains patterns souvent associés à des scans RewriteCond %REQUEST_URI (\.\./)+ [NC,OR] RewriteCond %REQUEST_URI (wp-admin/|wp-includes/) [NC] RewriteRule ^.*$ - [R=404,L]Attention: ce bloc est volontairement “agressif” dans sa forme. L’idée n’est pas de le copier-coller sans réfléchir, mais de comprendre la méthode: vous ciblez un motif, vous renvoyez un code, vous validez dans les logs. Ensuite, vous rendez la règle plus fine.
Si vous constatez des erreurs inattendues, la correction est souvent simple: vous resserrez le motif, ou vous basculez sur une règle conditionnelle qui exclut des chemins légitimes.
Sécuriser les téléchargements et les contenus statiques
WordPress s’appuie sur des fichiers statiques, médias, et parfois des téléchargements gérés via des routes. Le durcissement consiste ici surtout à éviter l’exposition de scripts déposés au mauvais endroit, et à empêcher l’exécution de PHP dans des répertoires où il ne devrait pas y en avoir.
Selon l’hébergement, la désactivation de l’exécution PHP dans un dossier précis peut être déjà prise en charge. Mais quand ce n’est pas le cas, .htaccess peut contribuer.
Exemple typique si votre hébergeur permet de restreindre l’exécution dans le dossier uploads:
# Empêcher l’exécution de PHP dans wp-content/uploads Require all deniedCette règle doit être adaptée au chemin réel sur votre serveur. Sur mutualisé, le chemin disque exact n’est pas forcément /var/www/html/.... Et parfois, vous n’avez tout simplement pas la possibilité d’utiliser dans .htaccess. Dans ce cas, il faut rester sur des directives qui s’appliquent au répertoire du .htaccess.
Je préfère dire les choses clairement: si vous ne connaissez pas le chemin physique, ne devinez pas. Sinon, vous aurez une règle qui ne s’applique pas, ou qui casse la conf.
Les règles WordPress et l’ordre de traitement: le point le plus sous-estimé
WordPress place souvent des règles de réécriture entre des marqueurs. L’ordre compte, car Apache exécute https://gardewp.fr/securite-wordpress/ les directives dans une séquence déterminée. Si vous ajoutez un RewriteRule avant le bloc WordPress, vous pouvez court-circuiter la logique qui transforme /bonjour en requête interne vers index.php.
Une façon pragmatique de travailler consiste à conserver l’intégralité du bloc WordPress existant, puis à insérer vos règles de sécurité de façon isolée.
Quand vous n’êtes pas sûr, faites une chose: ajoutez vos règles tout en haut, mais ne touchez pas aux RewriteRule de WordPress. Tant que vos règles utilisent plutôt Require et des , le risque de conflit avec les permaliens est plus faible.
Un “kit” de durcissement WordPress à adapter, pas à copier sans test
Les règles “génériques” fonctionnent parfois bien, mais votre site a ses particularités. Voici un cadre utile pour organiser ce que vous ajoutez. Je le donne sous forme courte, parce que l’idée est d’éviter deux erreurs classiques: empiler des règles inutiles, et oublier de tester.
- Masquer ou bloquer des fichiers sensibles avec Désactiver l’indexation de répertoires avec Options -Indexes Restreindre XML-RPC si vous n’en avez pas besoin Utiliser des règles de motif uniquement quand vos logs montrent le problème Vérifier l’impact sur les permaliens et sur l’accès au back-office
Ce cadre, à lui seul, ne vous protège pas contre une compromission côté application, mais il réduit clairement des parcours d’attaque courants.
Journaliser et observer: le retour d’expérience qui fait gagner du temps
Si vous avez déjà vu des 404 soudains dans les logs après modification, vous savez à quel point il est facile de “tirer sur le mauvais fil”. C’est pour ça que l’observation est une partie du durcissement, pas un détail.
Sur une fenêtre de test de quelques heures, repérez:
- les erreurs 403 et 404 qui frappent des pages réelles les erreurs 500 ou AH dans error.log, signe d’une directive invalide les motifs d’URL qui correspondent à vos règles de blocage
Mon conseil: testez depuis un compte admin et, si possible, depuis une session non connectée. WordPress peut servir différemment selon l’état de connexion, et certaines règles de sécurité ont un impact sur la navigation front. Sans test “admin”, on oublie parfois l’espace d’administration.
Cas concrets selon le type d’hébergement
Hébergement mutualisé avec Apache classique
C’est le cas où .htaccess a le plus de sens. Vous avez presque toujours la main sur les directives courantes, et le site utilise généralement Apache.
Dans ce scénario, les règles par fichiers (), Options -Indexes, et certains RewriteRule sont souvent efficaces.
Serveur avec Nginx en amont
Même si .htaccess existe parfois via un reverse proxy ou un contrôleur, Nginx peut prendre la main avant Apache. Résultat: vos règles peuvent ne jamais s’exécuter pour les requêtes concernées.
Dans ce cas, l’approche la plus fiable consiste à vérifier dans les logs Apache si les requêtes touchent réellement le mécanisme .htaccess. Si vous ne voyez rien, il faut déplacer la protection côté Nginx plutôt que compter uniquement sur .htaccess.
WordPress sur un environnement où le chemin disque varie
C’est le piège de la règle “empêcher l’exécution PHP dans uploads”. Si vous ne pouvez pas valider le chemin disque, vous ne pouvez pas valider l’impact.
Dans un tel contexte, je recommande de privilégier les règles sans , et de renforcer avec d’autres couches quand c’est possible.
Check d’intégration finale avant mise en ligne
Avant d’activer tout ce que vous avez modifié sur un site de production, passez par une dernière vérification. Elle évite les surprises liées aux thèmes et aux plugins.
Voici ma courte liste de validation:
- Les permaliens fonctionnent, pages et articles sans 404 Le login fonctionne pour un compte valide L’accès aux médias uploads affiche correctement les images Les endpoints utilisés par vos plugins (REST, XML-RPC si requis) répondent Les erreurs Apache restent stables dans error.log
Si une ligne échoue, ne “corrigez au hasard”. Revenez sur la dernière règle ajoutée, relisez les conditions et resserrez.
Notes de sécurité utiles (et pas spectaculaires)
Quelques points qui reviennent dans les maintenances WordPress, même quand .htaccess est bien fait:
- Si WordPress est vulnérable via un plugin, .htaccess ne va pas réparer la faille. Le durcissement n’est pas une substitution à la mise à jour. Les règles de blocage ne doivent pas masquer un problème de configuration plus profond. Par exemple, si vous autorisez l’écriture dans certains dossiers par erreur, bloquer des chemins ne fera que retarder le diagnostic. Les tentatives de scans sont normales. Le but n’est pas de supprimer tous les 404, mais de réduire les vecteurs faciles et de rendre l’intrusion plus coûteuse.
Le durcissement WordPress le plus efficace est souvent moins spectaculaire que ce qu’on imagine, il combine plusieurs couches, et il reste cohérent avec votre fonctionnement.
Exemple de .htaccess complet, à manier prudemment
Pour visualiser le mélange fréquent entre règles WordPress et ajouts de sécurité, voici un squelette. À vous d’intégrer vos règles dans le bon contexte, et de conserver le bloc WordPress tel qu’il est.
Ce squelette ne “remplace” pas votre .htaccess. Il sert à illustrer un principe: vos ajouts doivent être isolés et cohérents avec le bloc de réécriture existant.
Où vous gagnez le plus, concrètement
Les règles .htaccess performantes en durcissement WordPress sont celles qui:
- ciblent des chemins précis renvoient un code adapté (souvent 404 plutôt que “disponible mais refusé”, selon vos choix) n’interfèrent pas avec les permaliens et les assets s’alignent sur vos usages réels (XML-RPC, upload, endpoints API)
Si vous voulez une mesure simple du résultat, observez l’évolution des requêtes bloquées dans les logs après quelques jours. Quand la baisse de bruit est nette, vous avez un bon signal. Quand vous voyez des 404 sur des pages légitimes, vous avez une règle trop large, et il faut réajuster.
Si vous me donnez deux informations, je peux vous proposer une version de règles plus ajustée à votre cas: votre type d’hébergement (mutualisé Apache, VPS, reverse proxy) et si vous utilisez XML-RPC ou une application tierce pour WordPress.