Sécuriser WordPress avec le fichier .htaccess : Un Guide Complet
Protéger votre WordPress, c’est comme être le gardien d’une forteresse numérique. Et dans votre arsenal de défense, le fichier .htaccess est votre baguette magique – un petit bout de code aussi puissant que l’anneau unique, mais en beaucoup moins dangereux pour la santé mentale. Découvrez comment transformer ce simple fichier en bouclier impénétrable pour votre site.
Pourquoi le .htaccess est-il si important ?
Le fichier .htaccess est un fichier de configuration Apache qui permet de définir des règles de sécurité directement au niveau du serveur. C’est comme un vigile à l’entrée de votre site qui vérifie chaque visiteur avant de le laisser entrer.
Les 5 Piliers de Protection via .htaccess 🥇
1. 🔏 Protection contre les Injections SQL et XSS
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule .* index.php [F,L]
Ces règles agissent comme un bouclier contre les attaques les plus courantes :
- Bloque les tentatives d’injection de scripts malveillants
- Empêche la manipulation des variables globales PHP
- Protège contre l’exploitation des failles de sécurité via _REQUEST
2. ⛔ Blocage des Méthodes HTTP Dangereuses
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK) [NC]
RewriteRule .* - [F]
Imaginez ces règles comme des portes verrouillées :
- TRACE : Utilisé pour le débogage, peut révéler des informations sensibles
- DELETE : Protection contre la suppression non autorisée
- TRACK : Similaire à TRACE, potentiellement dangereux
3. 🖼️ Protection Anti-Hotlinking
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?votre-site.com [NC]
RewriteRule \.(jpg|jpeg|png|gif|webp)$ - [NC,F,L]
Cette protection est comme un copyright automatique pour vos images :
- Empêche le vol de bande passante
- Protège vos ressources médias
- Garde le contrôle sur l’utilisation de vos images
4. 🤖 Protection contre les Bots Malveillants
RewriteCond %{HTTP_USER_AGENT} ^$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|scan).* [NC]
RewriteRule .* - [F,L]
Ce système agit comme un détecteur de robots malveillants :
- Bloque les robots sans identifiant
- Stoppe les outils de scraping
- Empêche les aspirateurs de sites
- Bloque les scanners de vulnérabilités
5. 📕 Barrière de sécurité cruciale qui protège plusieurs types de fichiers sensibles
# 1. Autoriser UNIQUEMENT les fichiers d'installation WordPress dans wp-admin
<LocationMatch "^/wp-admin/(plugin|theme)-install\.php$">
Require all granted
</LocationMatch>
# 2. Protection avec RewriteRules
RewriteEngine On
# 2a. Exclure d'abord les fichiers d'installation autorisés
RewriteCond %{REQUEST_URI} !^/wp-admin/(plugin|theme)-install\.php$ [NC]
# 2b. Bloquer tous les autres install.php
RewriteCond %{REQUEST_URI} install\.php$ [NC]
RewriteRule .* - [F,L]
# 2c. Bloquer les autres fichiers sensibles
RewriteCond %{REQUEST_URI} ^.*/(wp-config\.php|mariju\.php|simple\.php|classwithtostring\.php|woh\.php|zero\.php|phpmailer\.lang-sv\.php|wso\.php|\.tmb|wp-apxupx\.php|nf_tracking\.php|adminfuns\.php|tempfuns\.php|classfuns\.php|cjfuns\.php|readme\.html|wp\.php|geju\.php|about\.php|license\.txt|debug\.log|error_log|php_error\.log|composer\.(json|lock)|package\.json|package-lock\.json|\.(git|svn|tmb|htaccess|env|config|yml|yaml|md|sql|conf|bak|dist|fla|psd|ini|log|sh|inc|swp|dist|cache|test|lock)|~)$ [NC]
RewriteRule .* - [F,L]
# 3. Protection supplémentaire avec FilesMatch
<FilesMatch "(wp-config\.php|wso\.php|readme\.html|\.tmb|about\.php|license\.txt|debug\.log|error_log|php_error\.log|composer\.(json|lock)|package\.json|package-lock\.json|\.(git|svn|htaccess|env|config|yml|yaml|md|sql|conf|bak|dist|fla|psd|ini|log|sh|inc|swp|dist|cache|test|lock)|~)$" [NC]>
Require all denied
</FilesMatch>
Ces fichiers sont en mode ninja : invisibles ET inaccessibles.
PS : Même Chuck Norris n’a pas les droits d’accès !
- Fichiers WordPress critiques
# Exemple non exhaustif wp-config.php|readme.html|license.txt
- wp-config.php : Contient les identifiants de base de données et clés secrètes
- readme.html : Révèle la version de WordPress
- license.txt : Fichier non essentiel pouvant révéler la version
Il y a aussi le fichier install.php qui est sensible mais il faut autoriser les installations de plugins/thèmes et bien bloquer le reste. D’où la précision en amont pour autoriser wp-admin/plugin-install.php et wp-admin/theme-install.php et ensuite bloquer tout le reste.
- Fichiers de logs et d’erreurs
Exemple non exhaustif debug.log|error_log|php_error.log
Logs qui peuvent révéler :
- Structure du site
- Chemins des fichiers
- Erreurs PHP
- Informations sensibles
- Fichiers de configuration de développement
Exemple non exhaustif composer\.(json|lock)|package\.json|package-lock\.json
- composer.json/lock : Dépendances PHP et versions
- package.json/lock : Dépendances NPM et versions
Peuvent révéler :
- Versions des packages
- Structure du projet
- Vulnérabilités potentielles
- Fichiers système et versionning
Exemple non exhaustif \.(git|svn|htaccess|env|config)
- .git : Répertoire de Git
- .svn : Répertoire SVN
- .htaccess : Configurations Apache
- .env : Variables d’environnement
- .config : Fichiers de configuration
- Fichiers de documentation et data
Exemple non exhaustif \.(yml|yaml|md|sql)
- yml/yaml : Fichiers de configuration
- md : Documentation Markdown
- sql : Dumps de base de données
- Fichiers de Développement et Backup
Exemple non exhaustif \.(conf|bak|dist|fla|psd|ini|log|sh|inc|swp|dist|cache|test|lock)
- bak/dist : Fichiers de backup/distribution
- fla/psd : Fichiers sources Adobe
- ini : Fichiers de configuration
- log : Fichiers de logs
- sh : Scripts shell
- inc : Includes PHP
- swp : Fichiers temporaires vim
- cache : Fichiers de cache
- test : Fichiers de test
- lock : Fichiers de verrouillage
Syntaxe et Fonctionnement
<FilesMatch "...$" [NC]>
Require all denied
</FilesMatch>
- $ : Fin du nom de fichier
- [NC] : signifie « insensible à la casse »
- ✅ Matchera : readme.html
- ✅ Matchera : README.html
- ✅ Matchera : ReAdMe.html
- ✅ Matchera : README.HTML
- Require all denied : Bloque tout accès
🎩 Le bonus
Les sites WordPress sont régulièrement la cible de scans automatisés cherchant des failles via des dossiers oubliés ou mal protégés (wp-admin, backup, temp…). Pour contrer ces tentatives d’intrusion, il est crucial de rediriger ces ‘faux’ chemins ailleurs, signalant clairement aux visiteurs malveillants que l’accès est interdit tout en permettant une meilleure traçabilité dans vos logs de sécurité.
RewriteRule ^(backup|new|old|wp|test|admin|wordpress|temp)(/.*)?$ - [R=403,L]
Pour détecter et contrer les tentatives de scan malveillantes sur votre WordPress, adoptez une stratégie en deux temps :
- Utilisez le plugin ‘Redirection‘ pour monitorer les 404 et gérer légitimement vos redirections courantes (articles supprimés, pages renommées…).
- Traitez les tentatives d’accès suspects (scans de dossiers sensibles, URLs malveillantes) directement dans le fichier .htaccess avec un code 403, qui est plus approprié qu’une 404 car il indique clairement que l’accès est interdit plutôt que ‘non trouvé’.
Cette séparation des responsabilités (plugin pour le légitime, .htaccess pour la sécurité) permet une meilleure organisation et maintenance de votre site.
⚠️ .htaccess : Le petit fichier aux Grands Pouvoirs
Jouer avec le fichier .htaccess, c’est un peu comme désamorcer une bombe dans un film d’action : un seul fil mal coupé et boom, votre site passe en mode écran bleu de la mort ! 💣 Plus sérieusement, l’ordre des règles dans ce fichier est aussi crucial que la chorégraphie d’un ballet – une directive mal placée et c’est tout le spectacle qui part en vrille, alors prenez le temps de tester chaque modification dans un environnement sécurisé avant de faire votre grande première en production. 🎭
🎯 Le mot de la fin
Bon, on vient de voir comment bricoler notre .htaccess pour protéger notre site. C’est un peu comme apprendre à faire sa propre serrure – certes, on pourrait acheter un système de sécurité tout fait, mais là au moins on sait exactement comment ça marche !
Pourquoi c’est important ?
- On comprend les mécaniques de base de la sécurité Apache
- On peut personnaliser finement nos protections
- On devient plus autonome pour diagnostiquer les problèmes
🔌 Les alternatives « clé en main »
Il existe effectivement des plugins de sécurité super pratiques comme Wordfence, Sucuri, iThemes Security, SecuPress, etc. qui font tout ça automatiquement (et même beaucoup plus). C’est un peu comme choisir entre :
- Cuisiner soi-même (notre approche .htaccess)
- Commander un plat tout prêt (les plugins)
💡 Le vrai plus ?
En comprenant comment fonctionne le .htaccess, la prochaine fois qu’un plugin de sécurité vous dira « j’ai modifié votre .htaccess », vous saurez exactement ce qu’il raconte !
Comme dirait un vieux sage du web : « Donne un plugin à un développeur, il sécurisera son site pour un jour. Apprends-lui le .htaccess, il comprendra les failles de sécurité pour toujours ! » 😉