Comment forcer HTTPS avec .htaccess

Pour forcer HTTPS sur l’ensemble du trafic dans Apache, ajoutez trois lignes au fichier .htaccess situé à la racine de votre site : RewriteEngine On, RewriteCond %{HTTPS} off et RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301].

Si vous avez déjà collé une règle de redirection trouvée sur un forum et regardé le navigateur boucler jusqu’à abandonner, la règle elle-même était probablement correcte. Ce qui casse généralement la configuration, c’est ce qui se trouve en amont de votre serveur.

Cette règle intercepte chaque requête arrivant en HTTP simple et émet une redirection permanente vers l’URL identique en HTTPS. Elle fonctionne sur Apache avec mod_rewrite activé et un certificat SSL déjà installé, et échoue de manière spécifique et prévisible lorsqu’un CDN ou un répartiteur de charge se trouve en amont de votre serveur d’origine. Ce guide vous présente d’abord la règle prête à l’emploi, puis les variantes pour domaine, dossier et www, ensuite les correctifs pour les boucles de redirection, et enfin la marche à suivre si vous n’utilisez pas Apache.

Avant de commencer : certificat SSL et mod_rewrite

Forcer HTTPS ne fonctionne que si un certificat TLS/SSL valide est déjà installé sur le domaine. Rediriger vers HTTPS sans certificat ne sécurise pas le site, cela le rend inaccessible derrière un avertissement de sécurité du navigateur. (« Certificat SSL » est le terme courant dans l’industrie ; le protocole est en réalité TLS.) Vérifiez que le certificat est actif en chargeant directement https://votredomaine.com dans un navigateur et en contrôlant la présence du cadenas avant de toucher au .htaccess.

La règle ci-dessous dépend du module mod_rewrite d’Apache, qui est activé par défaut sur la plupart des hébergements mutualisés et cPanel. Le fichier .htaccess se trouve à la racine de votre site, généralement dans public_html ou le répertoire racine du domaine. Modifiez-le via le Gestionnaire de fichiers de cPanel (activez « Afficher les fichiers cachés » pour voir les fichiers dotfiles), par FTP ou via SSH. Sauvegardez le fichier avant toute modification afin de pouvoir le restaurer en cas de dysfonctionnement d’une règle.

La règle .htaccess pour forcer HTTPS sur tout le trafic

Collez ceci dans le fichier .htaccess à la racine de votre site pour rediriger chaque requête HTTP vers HTTPS :

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

Ligne par ligne : RewriteEngine On active le moteur de réécriture. RewriteCond %{HTTPS} off déclenche la règle uniquement lorsque la connexion n’est pas déjà chiffrée. RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} reconstruit l’URL en HTTPS, et les variables %{HTTP_HOST} et %{REQUEST_URI} préservent le domaine et le chemin exacts demandés par le visiteur, de sorte que la règle fonctionne sur plusieurs domaines sans jamais forcer silencieusement le www.

Dans les drapeaux [L,R=301], R=301 émet une redirection permanente et L arrête le traitement des règles de réécriture à cette étape. Lors des tests, utilisez d’abord R seul (une redirection temporaire 302), car les navigateurs mettent les 301 en cache de manière agressive et une erreur est difficile à corriger ; passez à R=301 uniquement une fois que vous avez confirmé que la redirection se résout correctement.

Ne répétez pas RewriteEngine On. Si cette ligne existe déjà dans le fichier, ajoutez uniquement RewriteCond et RewriteRule en dessous.

Variantes : domaine spécifique, dossier et canonicalisation www

Pour forcer HTTPS sur un seul domaine lorsque plusieurs pointent vers la même racine de document, ajoutez une condition sur HTTP_HOST :

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

Le drapeau NC rend la correspondance du nom d’hôte insensible à la casse. Pour combiner HTTPS avec la canonicalisation www/non-www, htaccessbook documente l’encapsulation des deux redirections dans un bloc conditionnel mod_rewrite :

<IfModule mod_rewrite.c>
	RewriteEngine On

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

	RewriteCond %{HTTP_HOST} !^www\. [NC]
	RewriteRule (.*) https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

La version publiée de ce bloc suppose que RewriteEngine On apparaît plus tôt dans le fichier ; il a donc été ajouté ci-dessus pour que l’extrait fonctionne de manière autonome. La première règle bascule la requête vers HTTPS. La seconde ajoute www à un hôte qui en est dépourvu. Notez que [L] arrête le traitement dès qu’une règle correspond, de sorte qu’une requête HTTP simple sans www entraîne deux redirections au lieu d’une : d’abord vers HTTPS, puis vers l’hôte avec www. Encapsuler les règles dans <IfModule mod_rewrite.c> permet au site de rester accessible (en servant via HTTP) plutôt que de générer une erreur 500 si mod_rewrite n’est pas chargé.

Empiler ces règles manuellement devient fastidieux dès lors que vous combinez HTTPS, la canonicalisation www, quelques redirections et un bloc de mise en cache dans le même fichier — un drapeau erroné ou une règle dans le mauvais ordre peut vous causer des problèmes en production. Le générateur htaccess d’OpenReplay assemble le fichier à partir d’un ensemble de bascules : forcer HTTPS, ajouter ou supprimer www, ajouter des redirections 301 ou 302, activer gzip et la mise en cache navigateur, bloquer des adresses IP, mapper des pages d’erreur personnalisées. Le résultat est commenté, se met à jour au fil de vos modifications, et s’exécute entièrement dans votre navigateur, ce qui vous permet de le copier ou de le télécharger pour le comparer à votre configuration existante.

Corriger ERR_TOO_MANY_REDIRECTS derrière un CDN ou un répartiteur de charge

Si votre redirection provoque ERR_TOO_MANY_REDIRECTS, le navigateur a suivi trop de sauts et a abandonné. La cause habituelle est un proxy ou un répartiteur de charge qui termine le TLS. Le TLS se terminant au niveau du proxy, %{HTTPS} n’est jamais on au niveau du serveur d’origine, la règle se déclenche à chaque requête et la boucle ne se rompt jamais. La solution consiste à se fier au schéma transmis par le proxy :

<IfModule mod_rewrite.c>
	RewriteEngine On
	RewriteCond %{HTTP:X-Forwarded-Proto} !https
	RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
</IfModule>

Ici, RewriteCond %{HTTP:X-Forwarded-Proto} !https lit l’en-tête X-Forwarded-Proto défini par le proxy, de sorte que la règle ne se déclenche que lorsque la connexion du visiteur d’origine était en HTTP. Testez avec R avant de passer à R=301.

Une boucle avec le SSL Flexible de Cloudflare est un problème différent avec une solution différente. Avec le chiffrement Flexible, le trafic entre Cloudflare et votre serveur n’est pas chiffré, de sorte qu’une règle d’origine qui exige HTTPS continue de renvoyer la requête en boucle. Cloudflare propose deux solutions : supprimer la redirection HTTPS au niveau du serveur d’origine, ou passer la zone en mode Full ou plus strict, ce qui nécessite un certificat sur le serveur d’origine lui-même. Ces modifications s’effectuent dans le tableau de bord Cloudflare, et non dans .htaccess. Un visiteur en mode Flexible navigue toujours en HTTPS, et le schéma que Cloudflare indique dans X-Forwarded-Proto reflète la connexion du visiteur lui-même, de sorte que le test d’en-tête ci-dessus ne provoquera pas de faux positifs. Corriger le mode de chiffrement reste néanmoins la vraie solution.

Après chaque modification, videz le cache et les cookies de votre navigateur avant de retester, car un 301 mis en cache peut masquer un correctif. Une boucle conditionnelle qui n’affecte que les utilisateurs arrivant via un chemin proxifié particulier est invisible lors d’un test manuel unique depuis votre propre navigateur. La relecture de session sur un site après migration peut révéler cette boucle de redirection intermittente — ainsi que les problèmes de contenu mixte — sous la forme d’un schéma de rebonds infinis que rencontrent de vrais utilisateurs.

Quand .htaccess n’est pas le bon outil

.htaccess est spécifique à Apache et n’est lu que sur les hébergements basés sur Apache. Avec Nginx, il n’existe pas de fichier .htaccess. Vous forcez HTTPS avec un bloc serveur qui écoute sur le port 80 et retourne une redirection :

server {
    listen 80;
    server_name votredomaine.com www.votredomaine.com;
    return 301 https://$host$request_uri;
}

Conservez return 301 uniquement dans le bloc du port 80 ; le placer dans le bloc 443 recrée la boucle. Sur les architectures modernes, l’application du HTTPS appartient souvent à la couche CDN, plateforme ou répartiteur de charge plutôt qu’à la configuration du serveur.

Une fois votre redirection opérationnelle, renforcez-la avec un en-tête HSTS afin que les navigateurs se connectent automatiquement en HTTPS et évitent entièrement la requête HTTP non sécurisée. HSTS est défini dans la RFC 6797 ; la fiche pratique HSTS de l’OWASP recommande Strict-Transport-Security: max-age=63072000; includeSubDomains; preload. Traitez preload comme une porte à sens unique : faire retirer un domaine de la liste est un processus long, et dans l’intervalle, les visiteurs peuvent se retrouver bloqués sur le domaine et tout ce qui en dépend si vous devez un jour revenir au HTTP.

Choisissez la règle adaptée à votre configuration, déployez-la avec une redirection temporaire 302, vérifiez que la redirection se résout en un seul saut, puis passez à une redirection permanente 301 et ajoutez HSTS par-dessus. Cette séquence force HTTPS sans les boucles de redirection et les erreurs mises en cache qui transforment un changement de cinq minutes en incident de production.

FAQ

Quelle est la différence entre une redirection 301 et une redirection 302 lors du forçage de HTTPS ?

Une redirection 301 est permanente et une 302 est temporaire. Les navigateurs mettent les 301 en cache de manière agressive et les conservent longtemps, ce qui rend difficile la correction d'un 301 erroné. Lors du test d'une redirection HTTPS, utilisez d'abord R (une 302) dans les drapeaux de RewriteRule, confirmez que la redirection se résout correctement en un seul saut, puis passez à R=301 pour la version permanente.

Comment vérifier que ma redirection HTTPS se résout correctement plutôt que de simplement vider le cache de mon navigateur ?

Exécutez curl -IL http://votredomaine.com en ligne de commande. Le drapeau -I demande uniquement les en-têtes et -L suit les redirections, ce qui vous permet de voir la chaîne complète. Une configuration correcte retourne un seul 301 avec un en-tête Location pointant vers l'URL https, puis un 200 sur l'adresse sécurisée. Si vous voyez des 301 répétés ou une redirection vers http, vous avez une boucle. C'est déterministe, contrairement à l'inspection d'un onglet de navigateur mis en cache.

Pourquoi ma redirection HTTPS génère-t-elle une erreur 500 au lieu de rediriger ?

Une erreur 500 signifie généralement que mod_rewrite n'est pas chargé, mais que votre règle appelle directement RewriteEngine ou RewriteRule. Encapsulez les règles dans un bloc IfModule mod_rewrite.c afin qu'Apache les ignore et serve via HTTP plutôt que d'échouer si le module est absent. Sur la plupart des hébergements mutualisés et cPanel, mod_rewrite est activé par défaut, mais le bloc conditionnel reste la pratique sécurisée si vous ne pouvez pas le confirmer.

La règle HTTPS dans .htaccess fonctionne-t-elle avec AWS Application Load Balancer ou d'autres proxies qui terminent le TLS ?

Pas avec la règle standard %{HTTPS} off. Lorsqu'un ALB AWS ou un répartiteur de charge similaire termine le TLS, la connexion chiffrée s'arrête au niveau du proxy et votre serveur d'origine Apache ne voit toujours que du HTTP simple, donc %{HTTPS} n'est jamais on et la règle boucle avec ERR_TOO_MANY_REDIRECTS. Utilisez plutôt RewriteCond %{HTTP:X-Forwarded-Proto} !https, qui lit l'en-tête défini par le proxy pour indiquer le protocole d'origine du visiteur.