Générateur .htaccess, gratuit

Qu'est-ce qu'un .htaccess ?

Le fichier .htaccess est un fichier de configuration pour les serveurs web Apache. Il permet de définir des redirections d'URL, des en-têtes de sécurité, des règles de cache et plus encore · sans modifier la configuration principale du serveur.

Questions fréquentes

Où placer le fichier .htaccess ?

Placez-le dans le répertoire racine de votre site (généralement public_html ou www). Les règles s'appliquent à ce répertoire et à tous ses sous-répertoires.

Cela fonctionnera-t-il avec Nginx ?

Non. .htaccess est spécifique à Apache. Nginx utilise sa propre syntaxe de configuration dans nginx.conf ou les fichiers de config de site.

.htaccess peut-il ralentir mon site ?

Apache vérifie le .htaccess à chaque requête, donc les fichiers très volumineux peuvent ajouter des frais. Pour les sites à fort trafic, déplacer les règles vers la config Apache principale est plus rapide.

Ce qu'est réellement .htaccess

Un fichier .htaccess est le fichier de configuration par répertoire d'Apache. Le nom est largement compris comme une contraction de « hypertext access » (accès hypertexte), reflétant l'usage premier d'origine du fichier : restreindre l'accès aux documents hypertextes. Placez-en un dans n'importe quel répertoire et les directives s'appliquent à ce répertoire et à chaque sous-répertoire en dessous. Le fichier n'a pas de nom avant le point (c'est un fichier point Unix, masqué par défaut) et il doit être nommé exactement .htaccess (minuscules, point initial) pour qu'Apache le trouve avec le réglage AccessFileName par défaut.

Il y a un coût de performance réel. La documentation d'Apache est explicite : « si AllowOverride est configuré pour autoriser l'usage des fichiers .htaccess, Apache cherchera des fichiers .htaccess dans chaque répertoire. Ainsi, permettre les fichiers .htaccess entraîne une baisse de performance, que vous les utilisiez réellement ou non. » L'arborescence des répertoires est parcourue à chaque requête HTTP. Pour une requête vers /var/www/html/foo/bar/baz.html, Apache vérifie par stat /.htaccess, puis /var/.htaccess, puis /var/www/.htaccess, puis /var/www/html/.htaccess, et ainsi de suite, même quand aucun de ces fichiers n'existe. La recommandation d'Apache lui-même est d'utiliser des blocs <Directory> de la configuration principale lorsque c'est possible (analysés une seule fois au démarrage), et de réserver .htaccess aux environnements d'hébergement où vous n'avez pas accès à la configuration principale.

Quand vous en avez besoin (et quand non)

Apache liste deux cas d'usage légitimes pour .htaccess : les hébergeurs qui donnent aux utilisateurs un contrôle limité sans accès complet à la configuration du serveur, et les cas où les directives doivent différer entre sous-répertoires alors que le déployeur ne contrôle que le système de fichiers. En dehors de ceux-là, la documentation recommande explicitement de déplacer les règles dans des blocs <Directory> de la configuration principale.

nginx (le deuxième serveur web le plus populaire) ne prend pas du tout en charge .htaccess ; il rejette délibérément les fichiers de configuration par répertoire pour des raisons de performance, et toute la configuration réside dans nginx.conf et les éventuels fichiers de site inclus. Si votre projet est sur nginx, la sortie de ce générateur ne vous aidera pas : il vous faudra des blocs server / location dans le fichier de configuration nginx. Caddy utilise sa propre syntaxe Caddyfile avec HTTPS automatique via Let's Encrypt par défaut. LiteSpeed et OpenLiteSpeed prennent en charge .htaccess pour la compatibilité Apache. IIS utilise web.config.

Réécriture d'URL et le motif HTTPS canonique

La plupart du travail non trivial avec .htaccess utilise mod_rewrite, le moteur de réécriture d'URL d'Apache fondé sur des règles et bâti sur les expressions régulières étendues POSIX. La forme de base est RewriteRule pattern substitution [flags], éventuellement précédée d'une ou plusieurs conditions RewriteCond. Le bloc standard de forçage HTTPS :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Les drapeaux [L,R=301] signifient « c'est la dernière règle de ce tour » et « réponds avec un HTTP 301 Moved Permanently ». Un 301 est le bon choix pour les redirections permanentes : les moteurs de recherche transmettent l'équité de lien et les navigateurs mettent en cache agressivement. N'utilisez 302 (Found) que pour des redirections réellement temporaires, quand vous ne voulez pas que le déplacement soit mis en cache.

Derrière un répartiteur de charge ou un proxy inverse qui termine le TLS, le serveur d'origine voit du HTTP simple même quand le navigateur de l'utilisateur est en HTTPS : une règle RewriteCond %{HTTPS} off naïve redirige alors indéfiniment. La solution est de vérifier plutôt l'en-tête transmis : RewriteCond %{HTTP:X-Forwarded-Proto} !https. Le mode « Flexible SSL » de Cloudflare (le CDN parle HTTP à l'origine pendant que l'utilisateur utilise HTTPS) est la cause la plus fréquente de ce piège de boucle de redirection.

Choisissez entre la canonisation www et non-www avec un motif similaire. Choisissez un seul nom d'hôte canonique pour le SEO (évite les problèmes de contenu dupliqué) et pour la portée des cookies (un sous-domaine www reçoit par défaut des cookies différents de l'apex).

Compression et mise en cache

mod_deflate compresse en gzip les réponses textuelles, réduisant radicalement la taille de transfert sur le texte/HTML/CSS/JS. Enveloppez le bloc dans <IfModule mod_deflate.c> pour qu'il ne fasse pas planter le site sur les serveurs où le module n'est pas chargé. Brotli (mod_brotli) est le remplaçant moderne et utilise le même motif.

mod_expires définit les en-têtes Expires et Cache-Control: max-age. La syntaxe très répandue « access plus 1 year » signifie que la ressource peut être mise en cache pendant un an à partir du moment où l'utilisateur l'a récupérée. Un max-age long est correct pour les noms de fichiers de ressources hachés (app.abc123.js) ; un max-age plus court est correct pour le HTML et tout ce qui est mutable. Pour un contrôle plus fin, Header set Cache-Control "public, max-age=31536000, immutable" sur les fichiers hachés est la meilleure pratique moderne.

En-têtes de sécurité à connaître

• X-Frame-Options: SAMEORIGIN : empêche l'intégration de la page dans une <iframe> sur d'autres origines. Largement supplanté par le frame-ancestors de CSP.
• Content-Security-Policy : la défense principale moderne contre le XSS et le détournement de clic. Pour commencer : default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'. Resserrez au fil du temps.
• Strict-Transport-Security (HSTS) : indique au navigateur de ne jamais parler qu'en HTTPS à votre domaine. max-age=31536000; includeSubDomains est la base typique. N'ajoutez preload que lorsque vous êtes sûr que le HTTPS est permanent : une fois préchargé dans la liste HSTS du navigateur, le retrait est difficile.
• X-Content-Type-Options: nosniff : empêche les navigateurs de remettre en question l'en-tête Content-Type. L'en-tête n'a qu'une seule valeur.
• Referrer-Policy: strict-origin-when-cross-origin : la valeur par défaut moderne ; envoie l'URL complète aux requêtes de même origine, seulement l'origine aux requêtes d'origine croisée, et rien lors d'une rétrogradation HTTPS-vers-HTTP.
• Permissions-Policy : contrôle des fonctionnalités du navigateur comme la caméra, le microphone, la géolocalisation. A remplacé l'ancien en-tête Feature-Policy.
• X-XSS-Protection : largement déprécié. Le filtre a été retiré de Chrome et n'a jamais existé dans Firefox ; la sécurité moderne repose sur CSP. De nombreux anciens guides le fournissent encore pour les vieilles versions d'IE : sans danger à omettre sur les nouveaux sites.

Masquer ce qui ne devrait pas être servi

Deux lignes uniques de renforcement de la sécurité sont vite rentabilisées :

• Options -Indexes : désactive les listes de répertoires générées automatiquement quand il n'y a pas de index.html. De nombreuses distributions livrent l'indexation de répertoires activée par défaut ; un répertoire égaré et non protégé ne devrait pas divulguer son contenu sur le web.
• Bloquer les fichiers point et les métadonnées de gestion de versions. Un bloc <FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$"> avec Require all denied empêche les attaquants de télécharger .env (qui contient souvent des mots de passe de base de données et des clés d'API) ou .git/config (qui expose des URL distantes et parfois des identifiants). Les rapports de menaces d'Akamai et du SANS documentent l'exposition de .env comme l'une des fuites au niveau applicatif les plus courantes des années 2020.

Apache 2.4 a remplacé l'ancienne syntaxe Order Allow,Deny par la famille de directives Require, plus propre : Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5. L'ancienne syntaxe fonctionne toujours pour la rétrocompatibilité, mais est documentée comme dépréciée.

Pièges courants

• mod_rewrite doit être activé au niveau du serveur. Sur Debian/Ubuntu : sudo a2enmod rewrite && sudo systemctl restart apache2. Sans cela, chaque RewriteRule est silencieusement ignorée.
• AllowOverride compte. Si la configuration principale a AllowOverride None pour votre <Directory>, chaque directive de votre .htaccess est silencieusement ignorée. AllowOverride All autorise tout ; AllowOverride FileInfo AuthConfig n'autorise que la réécriture et l'authentification, ce qui suffit pour la plupart des cas d'usage.
• Une seule faute de frappe casse tout le site. Apache renvoie une erreur 500 Internal Server Error pour chaque requête vers l'arborescence de répertoires affectée jusqu'à ce que le fichier soit corrigé. Testez toujours d'abord en préproduction ; gardez une copie de sauvegarde nommée .htaccess.bak ; ayez un accès SSH/FTP prêt pour pouvoir renommer un fichier cassé à distance. Surveillez /var/log/apache2/error.log pour les messages de syntaxe.
• Boucles de redirection infinies. Les navigateurs plafonnent les chaînes de redirection à environ 20 sauts et affichent ERR_TOO_MANY_REDIRECTS. Les causes les plus courantes : une règle de redirection HTTPS s'exécutant sur un serveur derrière un proxy qui termine le TLS (utilisez %{HTTP:X-Forwarded-Proto}) ; des règles www et HTTPS dans le mauvais ordre provoquant des redirections doubles ; le mode Flexible SSL de Cloudflare.
• Le drapeau [L] relance le moteur de réécriture depuis le début avec l'URL réécrite. Si une règle ultérieure correspond alors, le comportement peut être surprenant. Utilisez [END] (Apache 2.3.9+) quand vous voulez vraiment un arrêt net.
• Le contexte par répertoire retire la barre oblique de tête. Dans .htaccess, RewriteRule ^index\.html$ home.html correspond ; RewriteRule ^/index\.html$ ne correspond pas. Cela fait trébucher tous ceux qui copient une règle d'un exemple de configuration principale.
• Certaines directives sont interdites dans .htaccess : <VirtualHost>, <Directory>, <Location>, Listen, ServerName sont réservées à la configuration principale. Le fichier par répertoire s'applique déjà implicitement à son propre répertoire.

Plus de questions

Où exactement placer le fichier ?

Dans le répertoire dont vous voulez contrôler le contenu. La plupart des utilisateurs d'hébergement mutualisé le placent dans la racine documentaire de leur site, public_html/, www/, ou htdocs/ selon l'hébergeur. Apache parcourt ensuite l'arborescence de répertoires en appliquant les règles à ce répertoire et à chaque sous-répertoire en dessous.

301 ou 302, quelle redirection utiliser ?

301 Moved Permanently pour les déplacements permanents. Les moteurs de recherche transfèrent l'équité de lien vers la nouvelle URL ; les navigateurs mettent en cache la redirection agressivement. Utilisez-le pour les cas « nous avons déplacé cette page pour toujours ». 302 Found pour les redirections temporaires : le navigateur ne met pas en cache et les moteurs de recherche ne transfèrent pas le classement. N'utilisez 302 que lorsque le déplacement est réellement temporaire ; choisir 302 par défaut au lieu de 301 est l'une des bourdes SEO les plus courantes.

Comment protéger un répertoire par mot de passe ?

Créez un fichier .htpasswd avec l'utilitaire en ligne de commande htpasswd (il stocke des lignes username:bcrypt-hash) et stockez-le en dehors de votre racine web. Puis, dans .htaccess : AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user. Le navigateur affiche une invite d'authentification Basic système à quiconque visite le répertoire. C'est le motif Apache classique ; pour une authentification sérieuse, envisagez plutôt un système de connexion au niveau applicatif.

Cela fonctionnera-t-il sur WordPress ?

WordPress est livré avec son propre bloc .htaccess (entre les marqueurs # BEGIN WordPress et # END WordPress) qui gère les permaliens. WordPress écrasera tout ce qui se trouve à l'intérieur de ces marqueurs quand vous enregistrez les réglages de permaliens. Ajoutez vos propres règles en dehors des marqueurs WordPress (généralement au-dessus) pour qu'elles survivent à la régénération automatique.

Quelque chose est-il envoyé à un serveur ?

Non. Le générateur est du JavaScript qui assemble des blocs de directives en fonction de vos cases à cocher ; la sortie est construite dans votre navigateur. Rien de votre domaine ou des options choisies ne quitte la page ; l'outil fonctionne hors ligne une fois chargé.

Outils associés