Sécuriser le .htaccess WordPress : utile, mais pas magique
Le fichier .htaccess pilote une partie du comportement Apache : réécriture d’URL, redirections, accès à certains fichiers, cache, compression et parfois en-têtes HTTP. Sur WordPress, il est souvent modifié par le cœur, les plugins de cache, les extensions de sécurité ou les outils SSL. Il faut donc le renforcer sans le transformer en fourre-tout incontrôlable.
Commencer par les redirections propres
Un site doit choisir une version canonique : HTTPS, avec ou sans www, avec une stratégie claire sur les slashs et extensions. Les redirections doivent préserver le chemin demandé. Rediriger toutes les variantes vers la page d’accueil fait perdre de l’information aux visiteurs et brouille les signaux SEO.
Pour les anciennes URLs, une redirection 301 vers l’équivalent exact reste préférable : /ancienne-page.php vers /ancienne-page, pas vers /. Les canonicals doivent ensuite confirmer la même URL finale.
Protéger les fichiers sensibles
Le .htaccess peut empêcher l’accès direct à certains fichiers : logs, sauvegardes, exports SQL, fichiers commençant par .ht, configuration privée, dossiers de dépendances ou scripts de test. La règle est simple : ce qui n’est pas nécessaire au navigateur ne doit pas être servi.
<FilesMatch "^\\.(ht|env)">
Require all denied
</FilesMatch>
Options -Indexes
Options -Indexes évite l’affichage de la liste des fichiers lorsqu’un dossier n’a pas d’index. Ce n’est pas une protection suffisante pour un fichier sensible, mais c’est une base indispensable.
Ajouter des en-têtes HTTP cohérents
Les en-têtes de sécurité réduisent l’impact de certaines erreurs. Ils doivent être adaptés au site réel, surtout si des scripts externes, iframes ou polices CDN sont utilisés.
- Strict-Transport-Security force HTTPS après première visite.
- X-Content-Type-Options limite le sniffing MIME.
- Referrer-Policy contrôle les informations transmises aux sites tiers.
- Permissions-Policy désactive les APIs navigateur inutiles.
- Content-Security-Policy encadre les sources de scripts, styles, images et frames.
Une CSP trop large ne sert presque à rien. Une CSP trop stricte peut casser le site. Il faut l’inventorier, la tester, puis la resserrer progressivement.
Ce que le .htaccess ne remplace pas
Il ne corrige pas un plugin vulnérable, un mot de passe faible, un upload mal validé ou un compte administrateur compromis. Il ne doit pas non plus contenir des règles copiées sans compréhension. Une mauvaise règle peut créer une boucle de redirection, exposer une ancienne URL ou bloquer Googlebot.
Checklist opérationnelle
- Forcer HTTPS et le domaine canonique en conservant le chemin.
- Rediriger les anciennes extensions vers les URLs propres.
- Bloquer logs, dumps, dossiers de dev et fichiers cachés.
- Désactiver l’indexation de dossiers.
- Ajouter les en-têtes HTTP utiles, testés sur le site réel.
- Documenter chaque règle ajoutée.
Un bon .htaccess est court, lisible et vérifiable. Il doit soutenir la sécurité et le SEO sans devenir une zone obscure que plus personne n’ose toucher.
