La plupart des attaques contre WordPress ne commencent pas par un exploit “magique”. Elles commencent par quelque chose de très banal: un bot qui scanne des URL, des tentatives de connexion, une tentative de lecture d’un fichier sensible, ou une curiosité malveillante vers des endpoints jamais censés être exposés. Dans ce contexte, le fichier .htaccess reste un levier concret, simple à déployer, et souvent sous-estimé.
Sur Apache, .htaccess permet d’agir au niveau de la requête, avant même d’arriver à WordPress. On peut filtrer, restreindre des chemins, réduire la surface d’exposition et mieux encadrer certains comportements. Attention, ces directives ne remplacent pas le durcissement côté serveur, ni les bonnes pratiques (mises à jour, mots de passe solides, plugin raisonnés). Elles s’intègrent plutôt dans une stratégie de défense en profondeur.
Je vous propose ci-dessous des directives et des idées d’usage “qui tiennent en production”, avec les compromis à garder en tête, les erreurs fréquentes, et des exemples concrets.
Ce que .htaccess peut vraiment faire (et ce qu’il ne fera pas)
Avant de copier-coller, il faut être clair sur le rôle de .htaccess. Ce fichier est interprété par Apache au niveau du répertoire. Il s’applique donc aux requêtes qui passent sous ce chemin. En pratique, quand WordPress est installé dans un dossier, c’est ce .htaccess là qui influence le trafic entrant.
Ce que vous pouvez faire efficacement:
- bloquer l’accès à des fichiers ou répertoires précis (ou à certains types de requêtes) réduire l’exposition de zones “inutilement publiques” limiter certaines classes d’attaques triviales, notamment celles basées sur la découverte d’URL ou la lecture de fichiers renforcer des contrôles liés aux redirections et à la cohérence des requêtes
Ce que vous ne devez pas en attendre:
- un pare-feu complet contre toute attaque web (ce rôle revient plutôt à la config serveur, à un reverse proxy, ou à un WAF) une protection contre des failles applicatives internes à WordPress ou à un plugin une immunité contre les attaques par force brute si vous ne contrôlez pas aussi la couche d’authentification
Le bon réflexe, c’est de considérer .htaccess comme un sas de sécurité. Un sas utile, mais pas un bunker.
Prérequis: Apache, permissions, et emplacement du fichier
Les directives ci-dessous sont pensées pour Apache. Si votre hébergement est en Nginx, elles ne s’appliqueront pas. Sur Apache, vérifiez aussi:
- que Apache autorise l’usage de .htaccess (directive AllowOverride côté configuration vhost) que le .htaccess est bien placé à la racine WordPress (là où WordPress s’attend à ce que les règles de réécriture fonctionnent) que les permissions du fichier et du dossier permettent bien la lecture par Apache
Une erreur courante que j’ai vue sur plusieurs sites: le propriétaire du site a déplacé WordPress dans un sous-dossier, puis a gardé le vieux .htaccess en haut d’arborescence. Résultat, les règles de redirection ne s’appliquaient plus, WordPress affichait des 404 bizarres, et le site a basculé en mode “ça ne marche plus”. Si vous testez, faites-le sur un environnement de préproduction ou au moins avec un plan de restauration.
Empêcher la lecture de fichiers sensibles
WordPress est souvent exposé à la curiosité de scanners. Ils ne cherchent pas toujours “un exploit”, ils cherchent surtout des fichiers qui ne devraient jamais sortir: fichiers de configuration, backups, archives, logs, ou fichiers dans le répertoire wp-content qui ne doivent pas être publics.
Une première série de règles consiste à bloquer certains chemins. Sur Apache, on peut le faire via Require all denied, ou via des règles plus anciennes. Je vous recommande une approche moderne et claire, et de conserver une logique cohérente avec la configuration actuelle de votre serveur.
Voici le type de blocage que j’utilise généralement, adapté à des cas “classiques”:
- bloquer wp-config.php et ses variantes bloquer les backups et fichiers temporaires qui traînent parfois (extensions comme .bak, .old, .swp) bloquer l’accès aux dossiers secrets (selon votre organisation, il peut s’agir de certains répertoires d’upload non publics)
Sur le plan sécurité, le gain est surtout opportuniste: vous réduisez le bruit des scanners, et vous évitez des fuites accidentelles.
Point d’attention sur les backups
Oui, on bloque des extensions comme .bak, mais dans la réalité certaines équipes stockent des archives dans un répertoire d’assets accessible. En bloquant trop agressivement, on peut casser des workflows. Le compromis est simple: si vos backups ne doivent pas être publics, gardez-les hors de la racine web ou dans un répertoire non exposé. Si vous ne pouvez pas, bloquez seulement ce qui pose problème, et validez avec un test avant mise en ligne.
Sécuriser la zone wp-includes, wp-content, et limiter les accès directs
Une autre ligne de défense consiste à restreindre l’accès à certains fichiers PHP ou à certains types de requêtes. Par exemple, sur beaucoup de sites WordPress, on ne veut pas que des fichiers PHP “statiques” au sens large soient accessibles directement. Dans la pratique, WordPress sert déjà des pages via index.php, et Apache fait ensuite le routing via mod_rewrite.
Ici, le danger, c’est la casse. Une règle trop large peut bloquer un endpoint légitime, ou empêcher l’exécution de PHP pour certains fichiers prévus. Pour éviter ce piège, je privilégie une approche ciblée, par exemple:
- bloquer des fichiers précis ou restreindre l’accès à des dossiers qui ne doivent jamais être servis par le navigateur
Si vous voulez une règle simple et efficace sans toucher au coeur du routing, commencez par le blocage des fichiers qui n’ont aucune raison d’être accessibles.
Réduire les possibilités d’énumération et le bruit des bots
Les attaquants automatisent très vite la découverte d’URL. Vous pouvez rendre certaines tentatives inutiles en filtrant des motifs trop évidents: requêtes vers des fichiers sans intérêt, patterns d’exploration de répertoires, ou des URLs manifestement malformées.
Mais là aussi, l’excès nuit. J’ai déjà vu des règles qui “nettoyaient” de façon trop radicale, puis qui cassaient un plugin qui appelait une URL spécifique via AJAX, ou un mécanisme de redirection interne.
La meilleure stratégie est d’ajouter des garde-fous progressifs, et d’observer les logs après déploiement. Si votre hébergement fournit un accès aux logs Apache, https://gardewp.fr/securite-wordpress/ cherchez:
- les codes 403 et 404 qui augmentent fortement les requêtes qui ressemblent à du faux positif la corrélation avec des plaintes utilisateurs
Contrôler le trafic malveillant sans casser le site
Une approche utile est de limiter l’accès à certains endpoints à certaines conditions. Sans aller jusqu’à écrire un pare-feu complet dans .htaccess, vous pouvez déjà filtrer des comportements grossiers, par exemple:
- bloquer des paths “connus” pour être explorés refuser des formats de requête qui n’ont aucune raison d’être acceptés forcer une cohérence sur les redirections
Si votre WordPress reçoit du spam sur wp-login.php, .htaccess peut aider, mais souvent ce n’est pas le meilleur endroit pour faire du rate limiting complet. Selon votre offre d’hébergement, les options varient: mod evasive, modsecurity, ou des règles côté proxy. Néanmoins, vous pouvez au moins réduire la surface.
Directives de base que j’aime garder “propres”
Il y a aussi des directives qui servent à la robustesse générale, par exemple:
- désactiver la liste de répertoires (Indexing) éviter l’affichage d’erreurs trop détaillées via la configuration PHP ou serveur s’assurer que les réécritures fonctionnent correctement et ne laissent pas passer des URL inattendues
Ces points sont moins “sexy” que le blocage d’un fichier, mais ils réduisent les cas où un attaquant apprend quelque chose par observation.
Une checklist réaliste avant de toucher au .htaccess
Sauvegardez votre .htaccess actuel, copiez aussi le fichier de déploiement précédent si votre hébergeur en conserve une version. Vérifiez que le site fonctionne encore avec un test en navigation privée, pas seulement avec votre session connectée. Contrôlez les logs Apache pendant 30 à 60 minutes après changement, surtout autour des 403. Commencez par des règles “bloqueuses” de chemins précis, évitez les restrictions globales tant que vous n’avez pas observé l’impact. Gardez une règle de retour en arrière prête, par exemple un second fichier .htaccess-test si votre environnement le permet.C’est un rituel simple, mais c’est ce qui m’a évité plusieurs retours utilisateurs après des règles trop enthousiastes.
Un exemple concret: quand trop de règles ont cassé le routing
Je me souviens d’un cas sur un site éditorial. L’objectif était la sécurisation WordPress avec un .htaccess “plus strict”. L’équipe avait ajouté un blocage de fichiers PHP basé sur des motifs de nom. Le problème, c’est que le thème et quelques plugins faisaient des inclusions dynamiques ou utilisaient des fichiers PHP qui ne respectaient pas exactement les suppositions de la règle. Résultat, certaines pages chargées via les appels AJAX échouaient en production, uniquement quand le cache activait certaines variantes.
Le correctif a été trivial sur le papier, mais exigeant en méthode: on a retiré les règles trop générales, puis on a remplacé par un blocage ciblé sur les chemins et fichiers vraiment sensibles. Le site a retrouvé sa stabilité, et la sécurité a continué de progresser, mais sans “stopper le moteur”.
Ce genre d’histoire revient souvent. Le moral: la sécurité, c’est aussi le contrôle des effets de bord.
Directives spécifiques: l’idée derrière chaque famille de règles
Plutôt que de vous imposer un bloc unique, je préfère expliquer les familles de directives, car c’est là que les erreurs apparaissent.
1) Bloquer l’accès aux fichiers de configuration et backups
Principe: aucun utilisateur normal ne doit lire wp-config.php, ni des backups jamais destinés au public. Ce sont des fichiers très informatifs si exposés.
- Fichiers WordPress sensibles: wp-config.php, et éventuellement les backups ou copies. Archives et temporaires: certains systèmes génèrent .bak, .zip, .tar, ou des fichiers temporaires selon les plugins.
Trade-off: si vous utilisez un processus de restauration qui laisse des fichiers dans la racine web, vous devez ajuster. La règle ne doit pas punir un fonctionnement légitime, elle doit punir l’exposition accidentelle.
2) Bloquer l’exploration de répertoires
Principe: empêcher la liste des contenus si un répertoire est accessible mais pas forcément “prêt” pour le public. Même si un répertoire n’affiche pas de contenu, la simple liste peut donner des indices.
Trade-off: certains scripts internes peuvent s’appuyer sur des listes pour des outils d’administration. Dans ce cas, on restaure l’accès seulement aux IP autorisées, ou on déplace le répertoire.
3) Renforcer les règles de réécriture
Principe: sur WordPress, mod_rewrite fait le routing. Si votre .htaccess est trop modifié, vous pouvez casser la façon dont WordPress résout les URLs. Une règle de sécurité ne doit pas empêcher la résolution normale.
Trade-off: plus vous “écrasez” les règles de WordPress, plus vous risquez des effets secondaires. Donc, on ajoute des règles au-dessus ou en périphérie, mais on respecte le bloc WordPress de réécriture.
Utiliser des règles “modernes” quand c’est possible (Require)
Selon la version d’Apache et la configuration, les règles basées sur Require all denied sont souvent plus lisibles. J’aime aussi leur compatibilité, car elles s’intègrent mieux dans des configurations plus récentes.
Sans rentrer dans une soupe de compatibilité, retenez l’idée: choisissez des directives cohérentes avec votre environnement. Si vous héritez d’un .htaccess ancien avec des règles “Order deny,allow”, évitez de mélanger sans comprendre. La sécurité, c’est aussi la lisibilité, pour pouvoir auditer plus tard.
Un mini plan de test avant d’aller plus loin
Si vous devez introduire une règle plus intrusive, testez en deux étapes:
- d’abord avec un blocage “shadow”, où vous observez le comportement sans empêcher l’accès réel ensuite, seulement après confirmation dans les logs, vous activez le blocage effectif
Selon votre hébergeur, on peut le faire via des règles qui renvoient une page temporaire ou des conditions de test. Si vous n’avez pas la liberté de modifier, faites au moins un déploiement nocturne, ou pendant une fenêtre courte, avec un bouton de rollback.
Rate limiting et contrôle d’accès: quand .htaccess est le bon outil
Pour certains sites, .htaccess permet de limiter les accès à wp-login.php ou d’imposer des restrictions sur des endpoints. Mais ce n’est pas toujours le meilleur endroit, car cela dépend de modules disponibles.
Beaucoup d’hébergeurs ne permettent pas facilement d’installer mod evasive, modsecurity, ou d’autres briques avancées. Dans ce cas, le .htaccess peut servir à:
- restreindre à certaines IP pour des zones d’administration refuser l’accès à des URL sensibles sans les exposer au public ajouter des garde-fous de taille et de comportement
Si vous avez accès à des modules, vous pouvez faire plus. Si vous n’en avez pas, vous devez rester pragmatique: vous pouvez rendre des scans moins rentables, mais pas stopper une attaque déterminée.
Réduire l’exposition de l’administration sans casser les outils
WordPress expose l’accès à l’administration via /wp-admin/. On peut protéger davantage avec des restrictions, mais il faut garder en tête le confort d’usage.
Un piège classique: bloquer trop large et se retrouver avec un “déni” pour soi-même, notamment quand on travaille sur mobile, ou quand on change d’IP, ou quand on utilise un VPN. J’ai déjà vu des équipes se verrouiller hors du back-office, puis devoir passer par la console de l’hébergement pour corriger en urgence.
Le compromis que je privilégie:
- ne jamais bloquer totalement l’accès admin sans pouvoir ouvrir une porte de secours garder une règle d’exception pour votre plage d’IP habituelle tester depuis deux environnements de navigation distincts
Exemple de logique d’exception (à adapter)
Vous pouvez combiner une restriction basée sur l’accès au chemin avec une condition sur l’adresse IP. Si votre serveur est derrière un proxy, l’IP vue peut être celle du proxy, donc la condition ne marchera pas comme prévu. Dans ce cas, il faut comprendre votre chaîne réseau. C’est là que les “règles prêtes à coller” sur Internet sont souvent décevantes.
Sécuriser avec cohérence: HTTPS, redirections, et chemins relatifs
Même si ce sujet semble moins “sécurité” au sens strict, la cohérence HTTP/HTTPS est un facteur important. Une configuration incohérente peut faciliter des redirections mal contrôlées ou des sessions instables.
Dans .htaccess, on peut forcer une redirection vers HTTPS, ou empêcher l’accès en HTTP. Mais il faut le faire en connaissance de cause:
- si votre hébergement gère déjà le HTTPS, double redirection peut créer des boucles si vous êtes derrière un load balancer, Apache peut voir des requêtes en HTTP même si l’utilisateur a un HTTPS, et la détection doit se baser sur les en-têtes du proxy
Ce point est très concret: j’ai déjà corrigé une boucle de redirection sur un site où le .htaccess forçait HTTPS alors que le proxy en faisait autant. Le correctif a consisté à déléguer la responsabilité au bon niveau, et à laisser .htaccess tranquille.
Vérifier que vous ne cassez pas WordPress au passage
WordPress a son propre fonctionnement de routing. Chaque fois que vous modifiez des règles de réécriture, posez-vous la question: mes directives vont-elles s’exécuter avant ou après les blocs de WordPress ? Les effets de bord viennent souvent d’un ordre mal compris.
Conseil pratique: gardez votre .htaccess lisible, aérez les sections, et documentez en une phrase ce que fait chaque bloc. Quand vous revenez six mois plus tard, vous êtes content d’avoir une trace, surtout si un collègue a modifié autre chose entre-temps.
Où placer vos règles dans le .htaccess
En règle générale, je place les règles de sécurité “ciblées” dans des sections qui ne perturbent pas le cœur de WordPress. Par exemple, des règles de blocage de fichiers spécifiques peuvent aller avant la partie réécriture, tant qu’elles ne capturent pas des chemins que WordPress utilise pour router.
L’objectif n’est pas de “forcer” un ordre universel, mais de réduire les risques d’interaction. Si vous ne savez pas, faites une modification minimale et testez.
Deux garde-fous pour éviter les erreurs les plus coûteuses
Voici les erreurs qui coûtent du temps, de la réputation et parfois un retour service:
Bloquer un endpoint légitime: un plugin d’API, un fichier de thème, une ressource admin. Les symptômes ressemblent à des erreurs 403, des pages blanches, ou des scripts qui ne se chargent pas. Forcer une logique de redirection incompatible: boucle http vers https, ou redirection vers un domaine incorrect. Les symptômes sont rapides et pénibles, mais on peut les diagnostiquer avec l’historique du navigateur et les logs.La meilleure prévention est le test, et le déploiement progressif.
Règles utiles, mais à personnaliser pour votre site
La “meilleure” sécurisation WordPress dépend de votre usage. Un site vitrine n’a pas les mêmes contraintes qu’une boutique, et un site avec multisite ou des plugins spécifiques n’a pas la même arborescence. Deux paramètres changent tout:
- ce que vous exposez vraiment (thèmes, plugins, endpoints, REST API) votre modèle d’accès (IP fixes, utilisateurs mobiles, admin rarement connecté, etc.)
Donc, prenez ces directives comme une boîte à outils. Choisissez les actions qui correspondent à vos risques réels.
Checklist finale avant mise en ligne
Vérifiez que votre site charge correctement toutes les pages et que le back-office reste accessible depuis au moins deux environnements. Confirmez dans les logs que les 403 et 404 ne montent pas de façon anormale sur des URLs légitimes. Mesurez l’impact fonctionnel sur les formulaires, l’édition, et les appels AJAX si vous avez des plugins dynamiques. Gardez un plan de rollback immédiat, idéalement via un remplacement du .htaccess ou restauration d’un backup. Documentez vos changements dans un fichier interne ou dans un historique simple, pour garder la trace des décisions.Dernier mot: .htaccess est un levier, pas une fin
Quand on parle de sécurisation WordPress, on a tendance à chercher “le fichier magique”. .htaccess ne fonctionne pas comme ça. C’est un outil puissant, mais il demande de la discipline, du test, et une bonne compréhension de l’environnement Apache.
Si vous appliquez une logique cohérente, des blocages ciblés, et que vous surveillez l’effet réel dans les logs, vous obtenez un gain concret. Et surtout, vous construisez une posture défendable, où chaque règle a une raison d’être et un impact maîtrisé.
Si vous me dites votre configuration (Apache ou autre, présence de multisite, plugins importants, et si votre hébergeur utilise un proxy), je peux vous proposer une version de directives plus ajustée à votre cas, avec une approche plus prudente sur l’ordre des règles.