Générateur .htaccess — sécurité & HSTS

Que fait le générateur .htaccess ?

Le générateur est un éditeur pour règles de configuration Apache. Vous choisissez parmi 14 types de règles (redirections, réécritures, en-têtes de sécurité, forçage HTTPS, Cache-Control, blocage IP, protection anti-hotlink, HTTP Basic Auth et plus), ajustez chaque règle champ par champ et obtenez un .htaccess proprement structuré — avec gardes <IfModule> par règle, output dual optionnel <IfVersion> pour vieux hébergeurs mutualisés, et export Cloudflare Pages pour _headers et _redirects. Tout se passe dans le navigateur. Aucun upload, aucun compte, aucune bannière cookie.

Les quatre préréglages couvrent les configurations de stack les plus fréquentes :

• En-têtes de sécurité modernes — starter CSP, HSTS prêt pour Preload, Permissions-Policy, COOP, X-Content-Type-Options, Referrer-Policy.
• Site statique — performance — Cache-Control + Expires pour JS/CSS/images/polices, compression Deflate pour les MIME texte.
• Pipeline HSTS Preload — préparation complète pour la soumission hstspreload.org.
• Durcissement WordPress — protection pour wp-config.php, wp-includes, XML-RPC.

Quels types de règles sont intégrés ?

Quatorze types de règles, classés par fonction :

• Routing — redirect (301/302/303/307/308), pattern de rewrite, www ↔ non-www, forçage HTTPS, ajout ou suppression du slash final.
• Header — bloc d’en-têtes de sécurité avec CSP, Permissions-Policy, HSTS, COOP, Referrer-Policy.
• Accès — allowlist IP (site entier ou seulement zone admin), blocklist IP, HTTP Basic Auth avec realm et chemin .htpasswd.
• Contenu — documents d’erreur personnalisés (401/403/404/500), Directory Listing on/off, Cache-Control avec max-age et immutable, compression avec liste de MIME types.
• Protection — hotlink protection avec allowlist Referer.

Chaque règle affiche sous son en-tête les modules Apache requis en badge. Vous voyez d’un coup d’œil si votre hébergeur fournit mod_rewrite, mod_headers, mod_deflate et consorts.

Comment fonctionne le mode dual Apache 2.4 vs 2.2 ?

La plupart des hébergeurs mutualisés tournent en Apache 2.4 en 2026. Les directives d’accès ont cependant fondamentalement changé entre 2.2 et 2.4 : au lieu de Order Allow,Deny plus Allow from, la 2.4 utilise la nouvelle directive Require. Sur un hébergeur legacy, activez le mode dual 2.4+2.2 du générateur — il émettra alors les deux variantes syntaxiques enveloppées dans des blocs <IfVersion>. Apache ne lit que le bloc qui convient, et vous n’avez pas à maintenir deux .htaccess séparés.

Le compromis : <IfVersion> lui-même nécessite mod_version, présent sur la plupart des 2.4 mais pas sur tous les 2.2. Le générateur enveloppe donc en plus les blocs dual dans un garde <IfModule mod_version.c>.

Que fait la liste de contrôle HSTS Preload ?

Quand vous activez le flag HSTS dans une règle d’en-tête de sécurité, une liste de contrôle apparaît au-dessus de la liste des règles. Elle examine les autres règles et signale ce que la soumission hstspreload.org rejetterait :

• Manque-t-il une redirection HTTPS ? → signalé.
• includeSubDomains est-il présent dans l’en-tête HSTS ? → vérifié.
• preload est-il présent dans l’en-tête HSTS ? → vérifié.

Quand tout est vert, le lien ouvre directement le formulaire de soumission de hstspreload.org. Vous évitez ainsi le cas classique du domaine rejeté parce que le workflow de soumission a été mal compris.

Quels en-têtes de sécurité valent vraiment la peine ?

Les Mozilla Web Security Guidelines et l’OWASP Secure Headers Project listent les en-têtes suivants comme set obligatoire pour les applications web modernes. Le générateur les couvre tous :

• Strict-Transport-Security — force HTTPS dans les navigateurs pour la période à venir (max-age 1 an par défaut, prêt pour Preload). Obligatoire pour tout site qui a été un jour accessible en HTTP.
• Content-Security-Policy — allowlist pour scripts, styles, images, polices. Empêche le cross-site-scripting et le mixed-content. Complexe à régler, d’où l’avertissement validator.
• Permissions-Policy — bloque les API navigateur (caméra, micro, géolocalisation, Payment Request, capteurs) dont votre site n’a pas besoin. Par défaut : tout désactivé.
• Cross-Origin-Opener-Policy — same-origin isole la fenêtre contre les manipulations window.opener et débloque SharedArrayBuffer (pertinent pour outils WebAssembly).
• Referrer-Policy — strict-origin-when-cross-origin envoie le Referer complet uniquement au propre domaine, aux tiers seulement l’origine. Équilibre entre besoin analytics et privacy.
• X-Content-Type-Options — nosniff empêche les attaques de MIME-sniffing sur des fichiers à Content-Type non défini.

Le générateur enveloppe les six dans un unique bloc <IfModule mod_headers.c> et émet le bloc comme unité cohérente. Qui n’a pas besoin d’un en-tête désactive la case correspondante ou efface la valeur dans le champ texte — la ligne disparaît automatiquement de l’output.

Comment fonctionne l’export Cloudflare Pages ?

Cloudflare Pages ne lit pas de .htaccess. La plateforme attend en revanche deux fichiers à la racine web :

• _headers — motif de chemin plus en-têtes de réponse HTTP. Format : ligne de chemin + lignes Clé : Valeur indentées.
• _redirects — chemin source, chemin destination, code statut, une règle par ligne.

Le générateur émet les deux fichiers depuis la même liste de règles. Les en-têtes de sécurité et Cache-Control vont dans _headers, les règles de redirection / forçage HTTPS / canonical www / slash final vont dans _redirects. Il suffit de changer d’onglet d’output.

Un pain point fréquent est ainsi résolu : qui migre d’un hébergement mutualisé vers une plateforme Edge devrait sinon traduire manuellement son .htaccess en deux autres fichiers. Le générateur le fait automatiquement — même liste de règles, trois formats d’output.

Quelles erreurs surviennent le plus souvent ?

Trois classiques qui apparaissent régulièrement lors des déploiements production d’un nouveau .htaccess — et le générateur tente d’éviter chacun :

1. 500 Internal Server Error après upload — c’est presque toujours une directive sans module chargé. Classique : Header set … sur un hébergeur sans mod_headers. Le générateur enveloppe donc chaque règle dans un garde <IfModule>. Si vous voyez quand même une 500, vérifiez d’abord l’error.log de votre hébergeur.
2. Boucle infinie de redirection HTTPS derrière un reverse-proxy — Cloudflare et CDN similaires transmettent la requête déjà HTTPS-terminée ; Apache voit cependant %{HTTPS} à off, parce que la connexion Proxy → Origin est en HTTP. Solution : au lieu de %{HTTPS}, vérifiez %{HTTP:X-Forwarded-Proto}. Le générateur émet la variante standard ; derrière un CDN, ajustez la condition manuellement.
3. CSP bloque vos propres scripts inline — arrive quand la CSP standard est diffusée sans 'unsafe-inline' alors que votre page contient encore des scripts inline. Deux voies : sortir les scripts inline dans des fichiers séparés (voie propre, à long terme), ou autoriser explicitement les inlines restants via une whitelist nonce / hash. L’évaluateur CSP externe indique exactement quels inlines la policy bloque actuellement.

Ces trois pain points sont liés dans les réponses FAQ ; le générateur lui-même ne peut pas les empêcher, mais les communique honnêtement.

Comment la confidentialité est-elle gérée ?

Pure-client. Le générateur tourne entièrement dans le navigateur. Pas d’endpoint serveur pour validation de règles, pas d’appel télémétrie, pas de cookie, pas de compte. Quand vous fermez l’onglet, votre liste de règles disparaît — le générateur ne persiste rien. Qui a besoin d’un historique télécharge le .htaccess après chaque édition et le versionne dans le repo, où il a sa place de toute façon.

Qu’est-ce qui n’est volontairement pas construit ?

• Pas de convertisseur nginx — htaccess-to-nginx est un outil séparé du backlog, parce que les mappings de directives sont trop volumineux pour un onglet inline.
• Pas de générateur .htpasswd inline — le générateur de fichier de mot de passe est l’outil frère htpasswd-generator (à venir). La règle HTTP Basic Auth renvoie dans l’output au fichier nécessaire.
• Pas de méga-liste anti-bots — le sniffing par User-Agent est en 2026 largement inefficace comme protection et produit des faux positifs. Qui veut bloquer des bots utilise un WAF au niveau Edge.
• Pas de validation côté serveur — exigerait un roundtrip serveur, briserait la promesse pure-client. Pour les tests live, la FAQ renvoie au testeur externe de madewithlove.
• Pas d’éditeur de ruleset mod_security — trop spécialisé pour un outil générateur. Qui règle mod_security travaille directement avec la configuration OWASP-CRS.

Où trouver plus de détails ?

• Documentation Apache HTTP Server 2.4 — référence officielle des directives
• .htaccess sur Wikipédia — histoire, fonctionnement, exemples
• hstspreload.org — liste de soumission pour les domaines HSTS-Preload
• CSP Evaluator — validator externe pour valeurs Content-Security-Policy
• Documentation Cloudflare Pages Headers — référence syntaxe _headers
• Documentation Cloudflare Pages Redirects — référence syntaxe _redirects