HSTS : le guide complet pour activer Strict-Transport-Security et la preload list

⚡TL;DR

• HSTS (RFC 6797) indique au navigateur de ne contacter un domaine qu'en HTTPS pendant la durée définie par max-age, neutralisant les attaques sslstrip et le downgrade de protocole
• L'en-tête se compose de trois directives : max-age (obligatoire), includeSubDomains (couvre les sous-domaines) et preload (opt-in à la liste embarquée dans Chrome et dérivés)
• Pour être éligible à la preload list, il faut max-age supérieur ou égal à 31 536 000, includeSubDomains, preload et une redirection HTTP vers HTTPS sur le domaine apex
• La preload list est quasi irréversible : un retrait prend plusieurs mois et ne touche que les versions futures des navigateurs
• En avril 2026, environ 120 000 domaines sont dans la preload list de Chrome et seulement 35,7 % des sites ayant HSTS ont activé la directive preload

En 2009, Moxie Marlinspike présente sslstrip à Black Hat DC. L'outil intercepte le trafic HTTP d'un utilisateur sur un réseau public, remplace à la volée chaque lien et redirection HTTPS par son équivalent HTTP, puis relaie les requêtes en clair. L'utilisateur croit être protégé par TLS, alors que tout son trafic, y compris les cookies de session et les mots de passe, sort en clair sur le câble. À la même époque, l'extension Firefox Firesheep (octobre 2010) popularise le vol de session sur Facebook et Twitter depuis n'importe quel hotspot Wi-Fi ouvert.

HSTS (HTTP Strict Transport Security) est la réponse à ces attaques. Standardisé par la RFC 6797 en novembre 2012, il permet à un serveur HTTPS d'indiquer au navigateur qu'il doit, pendant une durée définie, ne communiquer avec le domaine qu'en HTTPS. Quand l'en-tête est reçu et mémorisé, le navigateur convertit localement toute requête http:// en https:// avant même d'envoyer le moindre paquet sur le réseau. La fenêtre d'interception lors de la première redirection disparaît.

En avril 2026, selon les études d'adoption AppSecSanta, seulement 35,7 % des sites qui envoient un en-tête HSTS utilisent la directive preload. Le Chrome HSTS Preload List contient environ 120 000 domaines, très loin du parc HTTPS mondial. HSTS reste donc sous-utilisé, souvent mal configuré, parfois activé avec des effets de bord inattendus sur des sous-domaines internes en HTTP.

Ce guide couvre trois objectifs : comprendre précisément ce que fait HSTS (et ce qu'il ne fait pas), configurer l'en-tête dans les cinq stacks web les plus courants, et soumettre proprement un domaine à la preload list sans casser l'infrastructure. Il s'adresse aux DevOps, SRE, administrateurs système et CTO de PME qui préparent un audit sécurité ou une soumission preload.

Qu'est-ce que HSTS ?

HSTS est un en-tête de réponse HTTP envoyé par un serveur HTTPS valide. Il annonce à l'agent utilisateur (navigateur, bibliothèque HTTP, agent automatisé compatible RFC 6797) que le domaine doit être contacté exclusivement en HTTPS pendant la durée précisée par la directive max-age.

Une fois l'en-tête reçu sur une connexion TLS valide, le navigateur enregistre localement ce qu'on appelle un « Known HSTS Host ». Pour toute requête ultérieure vers ce domaine, y compris celles déclenchées par un clic sur un lien http://, un signet enregistré ou une redirection 301 servie par un autre serveur, le navigateur réécrit l'URL en https:// avant l'envoi. La conversion est faite en mémoire, côté client, sans requête réseau intermédiaire.

Trois éléments rendent HSTS efficace :

1. La conversion est locale. Aucune requête HTTP n'est jamais émise vers un domaine connu en HSTS. Un attaquant en position de man-in-the-middle ne voit que du TLS.
2. Les erreurs de certificat sont fatales. Sur un domaine en HSTS, le navigateur supprime le bouton « Continuer quand même » que l'utilisateur pourrait cliquer sur une erreur TLS. Un certificat auto-signé injecté par un attaquant déclenche un blocage, pas un avertissement.
3. Le TTL côté navigateur est prolongé à chaque visite. Tant que l'utilisateur visite le site régulièrement, max-age est rafraîchi à chaque réponse, ce qui empêche l'expiration.

L'en-tête est standardisé et supporté par tous les navigateurs majeurs depuis 2011. Chromium 4.0.211, Firefox 4.0 (août 2010), Opera 12, Safari sur OS X 10.7.3, Edge dès ses débuts et Internet Explorer 11 l'implémentent. En avril 2026, la compatibilité est universelle : 98 % du trafic web mondial passe par un navigateur compatible HSTS.

Le problème que HSTS résout

sslstrip et le downgrade de protocole

Sans HSTS, la protection HTTPS d'un site présente un maillon faible : la première requête. Quand un utilisateur tape captaindns.com dans la barre d'adresse, le navigateur émet par défaut une requête en HTTP sur le port 80. Le serveur renvoie une redirection 301 vers https://captaindns.com. Cette première requête sort en clair. Un attaquant sur le réseau local peut l'intercepter.

L'attaque sslstrip fonctionne ainsi : l'attaquant se positionne entre l'utilisateur et la passerelle réseau (ARP spoofing, rogue access point, compromission DHCP). Il intercepte la requête HTTP initiale, la relaie vers le serveur légitime en HTTPS, reçoit la réponse, remplace tous les https:// par http:// dans le HTML, les en-têtes et les cookies, puis la renvoie en clair à l'utilisateur. Du point de vue du navigateur, tout semble normal : une page HTTP classique, sans erreur. L'utilisateur saisit son mot de passe, qui transite en clair jusqu'à l'attaquant, puis est relayé chiffré vers le serveur.

HSTS neutralise sslstrip pour les visites ultérieures. Après la première requête HTTPS réussie, le navigateur mémorise l'en-tête. La deuxième visite, même si elle commence par un clic sur un lien http:// ou une redirection d'un domaine tiers, ne sort jamais en HTTP. Le navigateur convertit localement l'URL avant le DNS, avant le connect(), avant tout trafic réseau.

La limite reste la toute première visite. Un navigateur qui n'a jamais reçu l'en-tête HSTS pour un domaine est vulnérable à sslstrip sur sa première requête. C'est exactement ce que la preload list corrige : la liste embarquée dans Chrome permet au navigateur de connaître les domaines en HSTS dès sa sortie d'usine, sans attendre une première connexion.

Vol de cookies et Firesheep

Firesheep, publié en octobre 2010, a démontré à grande échelle la trivialité du vol de session sur les réseaux publics. L'extension sniffait les cookies de session de Facebook, Twitter, Flickr et de nombreux autres sites qui servaient encore leurs utilisateurs authentifiés en HTTP (ou qui passaient à HTTPS uniquement pour la page de login puis redescendaient en HTTP). Sur un Wi-Fi de café, cliquer sur un utilisateur dans l'interface de Firesheep permettait d'accéder à son compte en un geste.

HSTS renforce la protection des cookies de deux manières. D'une part, en forçant HTTPS, il élimine la fuite du cookie sur une connexion non chiffrée. D'autre part, combiné à l'attribut Secure sur le cookie (qui interdit son envoi en HTTP) et HttpOnly (qui bloque l'accès JavaScript), il ferme les trois vecteurs principaux de vol de session réseau.

Avec la directive includeSubDomains, HSTS protège également les cookies définis sans spécifier de domaine explicite. Un cookie posé par www.captaindns.com sans Secure pourrait, sans HSTS, être envoyé à api.captaindns.com en HTTP si une sous-ressource y était chargée en clair. Avec includeSubDomains, toutes les requêtes vers n'importe quel sous-domaine sont forcées en HTTPS, et le cookie reste chiffré.

Bootstrap MITM et la preload list

La RFC 6797 §14.6 reconnaît explicitement la vulnérabilité du « bootstrap MITM » : un utilisateur qui visite un domaine pour la première fois n'a pas encore reçu l'en-tête HSTS, et sa requête HTTP initiale reste interceptable. C'est la fameuse fenêtre de première visite.

La preload list de Chromium résout ce problème en embarquant dans le code source du navigateur la liste des domaines en HSTS. Chrome, Firefox, Safari et Edge importent cette liste à chaque mise à jour. Pour un domaine présent, le navigateur sait qu'il doit utiliser HTTPS dès la toute première requête, sans même avoir visité le site. La fenêtre de bootstrap disparaît.

L'inscription est gratuite mais exigeante : max-age supérieur ou égal à 1 an, includeSubDomains, preload, redirection HTTP vers HTTPS sur le domaine apex. Une fois inscrit, le retrait demande plusieurs mois, car il faut attendre que toutes les versions déployées des navigateurs importent la nouvelle liste. Certains utilisateurs sur d'anciennes versions continueront de forcer HTTPS sur votre domaine pendant des années.

Anatomie de l'en-tête Strict-Transport-Security

La syntaxe est définie par la RFC 6797 §6.1. L'en-tête se compose d'une directive obligatoire (max-age) et de deux directives optionnelles (includeSubDomains, preload), séparées par des points-virgules.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Les directives sont insensibles à la casse (IncludeSubDomains est valide mais non canonique). Une directive inconnue est silencieusement ignorée par les navigateurs conformes. Si la syntaxe complète est invalide, l'en-tête entier est rejeté : une seule faute de frappe peut désactiver votre protection sans alerte visible. D'où l'importance de tester la configuration avec un outil dédié avant de déployer en production.

Règles de validité

Plusieurs règles strictes de la RFC 6797 influencent le déploiement :

• HTTPS obligatoire. Un en-tête HSTS reçu sur HTTP est ignoré (§8.1). Cette règle est cruciale : elle empêche un attaquant man-in-the-middle d'injecter un max-age=0 en HTTP pour désactiver HSTS chez une victime.
• Certificat valide obligatoire. L'en-tête n'est pris en compte que si la connexion TLS s'est établie sans erreur ni avertissement (§8.1). Un certificat expiré, un nom de domaine incorrect, une chaîne incomplète : tout cela empêche la mémorisation.
• Première occurrence seule. Si plusieurs en-têtes HSTS sont envoyés dans la même réponse, seule la première est traitée (§8.1). Attention aux middlewares, CDN et reverse proxies qui empilent leurs propres en-têtes.
• Pas d'adresses IP. HSTS ne s'applique qu'aux noms de domaine. Un site accessible via https://192.168.1.1 n'est pas concerné (§8.3).
• Tous les ports. HSTS couvre le domaine pour tous les ports. Un port 80 est automatiquement converti en 443, mais un port personnalisé reste sur son numéro.

Trois exemples canoniques

# Minimum viable : 1 an, sans sous-domaines
Strict-Transport-Security: max-age=31536000

# Recommandation OWASP : 1 an avec sous-domaines
Strict-Transport-Security: max-age=31536000; includeSubDomains

# Éligible preload list : 2 ans avec sous-domaines et opt-in preload
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

La troisième ligne est la configuration cible pour tout site public qui souhaite une protection maximale. Nous la détaillons section par section.

max-age : la durée de la politique

max-age est la seule directive obligatoire. Elle exprime en secondes la durée pendant laquelle le navigateur doit considérer le domaine comme « Known HSTS Host ». Quelques valeurs typiques :

Valeur	Durée	Usage
0	Immédiat	Suppression de la politique HSTS
300	5 minutes	Test initial, rollout prudent
3600	1 heure	Staging, validation courte
86 400	1 jour	Rollout progressif, J+1
604 800	1 semaine	Rollout progressif, semaine 1
31 536 000	1 an	Seuil minimum preload list (depuis 11 octobre 2017)
63 072 000	2 ans	Recommandation courante pour preload

Le compteur est réinitialisé à chaque réponse HTTPS qui contient l'en-tête. Concrètement, si votre site envoie max-age=31536000 et qu'un utilisateur visite une page par mois, la politique ne s'éteint jamais tant qu'il revient dans l'année. Inversement, si vous retirez brutalement l'en-tête, les navigateurs qui ont reçu la politique continueront de forcer HTTPS jusqu'à l'expiration locale. C'est un effet cliquet : HSTS n'est facile à activer que dans un sens.

Rollout progressif recommandé

OWASP et la cio.gov recommandent une activation progressive pour éviter de se retrouver coincé avec une politique d'un an sur un site encore en déploiement. Un plan type :

1. Jour 0 : max-age=300. 5 minutes. Vérifiez que la chaîne HTTPS fonctionne, que la redirection HTTP vers HTTPS est stable, que tous les contenus internes sont servis en HTTPS. Un retrait est trivial, la politique expire en 5 minutes.
2. Jour 1 : max-age=86 400. 1 jour. Observez les erreurs TLS remontées par votre système de monitoring, votre WAF et vos logs applicatifs pendant 24 heures. Surveillez particulièrement les redirections cassées vers des ressources internes.
3. Jour 7 : max-age=604 800. 1 semaine. Si le taux d'erreur TLS reste stable, passez à une semaine. Cette étape valide que les sous-domaines actifs sont tous accessibles en HTTPS.
4. Jour 14 : max-age=31 536 000. 1 an. La politique est stable, les utilisateurs sont protégés. Si vous visez la preload list, vous pouvez activer includeSubDomains et preload à cette étape après audit.

Ce rythme permet de revenir en arrière à chaque étape. Passer directement à 1 an sans test intermédiaire est l'erreur la plus fréquente : si un seul sous-domaine oublié casse après activation d'includeSubDomains, vous êtes bloqué pour un an côté navigateur.

Désactivation via max-age=0

La RFC 6797 §6.1.1 précise qu'une valeur de 0 signale au navigateur de supprimer la politique en cache. C'est le seul moyen de retirer HSTS proprement : servir pendant la durée précédente un en-tête avec max-age=0, attendre que les navigateurs reçoivent cette mise à jour, puis retirer complètement l'en-tête. Attention, cette désactivation n'est effective que sur HTTPS (§8.1). Un max-age=0 servi en HTTP est ignoré.

includeSubDomains : étendre la protection

La directive includeSubDomains étend la politique HSTS à tous les sous-domaines du nom d'hôte qui l'a envoyée. Envoyée depuis captaindns.com, elle couvre www.captaindns.com, api.captaindns.com, blog.captaindns.com, ainsi que tous les sous-sous-domaines (staging.api.captaindns.com, etc.).

La RFC 6797 §8.2 précise que le matching se fait label par label, de droite à gauche, insensible à la casse. Une politique HSTS déclarée à captaindns.com couvre donc toute la hiérarchie DNS en dessous. Inversement, une politique déclarée à www.captaindns.com ne couvre ni api.captaindns.com ni captaindns.com, car la racine n'est pas un sous-domaine de www.

Pourquoi c'est critique pour les cookies

Sans includeSubDomains, un attaquant peut contourner HSTS en forçant une requête HTTP vers un sous-domaine. Scénario classique :

1. L'utilisateur se connecte à https://captaindns.com protégé par HSTS, reçoit un cookie de session sans attribut Secure.
2. L'attaquant injecte une image <img src="http://blog.captaindns.com/pixel.png"> dans une page visitée par la victime (via XSS, un forum, ou un man-in-the-middle sur un autre site).
3. Le navigateur émet la requête en HTTP vers blog.captaindns.com et y attache automatiquement le cookie du domaine parent (car les cookies se propagent aux sous-domaines).
4. L'attaquant, positionné sur le réseau, capture le cookie en clair.

Avec includeSubDomains, la requête vers blog.captaindns.com est convertie en HTTPS avant l'envoi. Le cookie reste chiffré sur le câble. C'est pour cette raison que l'OWASP Cheat Sheet recommande systématiquement includeSubDomains dès que possible.

Les pièges à éviter

includeSubDomains a un effet de bord radical : tous les sous-domaines, y compris ceux qui ne sont pas publics, doivent servir HTTPS. Voici les pièges les plus fréquents, documentés par les communautés DevOps :

• Outils internes en HTTP. Un grafana.interne.captaindns.com servi en HTTP sur le réseau privé deviendra inaccessible aux utilisateurs qui ont déjà mémorisé la politique HSTS de captaindns.com.
• Environnements de staging. Un staging.captaindns.com avec un certificat auto-signé provoque des erreurs TLS fatales pour les équipes qui se connectent depuis des postes ayant visité la production.
• Sous-domaines historiques. Un ancien mail.captaindns.com servi par un fournisseur tiers en HTTP risque de casser les liens dans les vieux emails.
• Sous-domaines tiers. Un sous-domaine délégué à un fournisseur SaaS (support.captaindns.com pointant vers Zendesk par exemple) doit offrir HTTPS avec un certificat valide pour le nom délégué.

Avant d'activer includeSubDomains, faites un inventaire exhaustif. Les équipes les plus expérimentées passent par une phase de « shadow mode » : activer HSTS sans includeSubDomains pendant plusieurs semaines, corréler avec les logs DNS pour identifier les sous-domaines actifs, basculer uniquement après audit complet.

Alternative : HSTS au niveau sous-domaine

Si certains sous-domaines ne peuvent pas être basculés en HTTPS (legacy, contrat externe), une alternative est de déclarer HSTS individuellement sur chaque sous-domaine qui le peut, sans includeSubDomains au niveau racine. C'est plus verbeux mais ça évite de casser les sous-domaines en HTTP. Le coût : chaque sous-domaine doit maintenir sa propre politique, et vous ne pouvez pas être éligible à la preload list sans includeSubDomains sur l'apex.

preload : la liste embarquée

La directive preload est un opt-in par lequel le propriétaire du domaine déclare son intention de figurer dans la Chrome HSTS Preload List. Sans cette directive, le domaine ne sera pas accepté à la soumission, même s'il remplit tous les autres critères.

Les quatre conditions d'éligibilité

hstspreload.org exige, depuis le 11 octobre 2017, que l'en-tête servi par le domaine apex respecte quatre conditions :

1. max-age supérieur ou égal à 31 536 000 (1 an). Un max-age plus court est refusé.
2. includeSubDomains présent. La preload list couvre toujours l'arbre DNS complet.
3. preload présent. Déclaration d'intention explicite.
4. Redirection HTTP vers HTTPS sur le domaine apex. Si le serveur accepte des connexions sur le port 80, il doit renvoyer un 301 vers HTTPS. La redirection doit elle aussi servir l'en-tête HSTS.

Un certificat TLS valide et la capacité à servir tous les sous-domaines (y compris www) en HTTPS sont également requis. L'outil de soumission teste automatiquement ces conditions avant d'accepter la demande.

Le processus de soumission

Une fois les conditions remplies, la soumission se fait en trois étapes :

1. Test automatique. Sur hstspreload.org, entrez votre domaine. Le service teste l'en-tête HSTS, la redirection HTTP vers HTTPS, la disponibilité HTTPS des sous-domaines www. Les erreurs sont détaillées.
2. Soumission. Si le test passe, un bouton « Submit to the HSTS preload list » devient disponible. Confirmez après avoir lu les avertissements sur l'irréversibilité.
3. Intégration. Le domaine passe en statut pending. Il est intégré à la liste source de Chromium, propagée à Firefox, Safari, Edge. La propagation complète prend environ 6 à 12 semaines, selon les cycles de release des navigateurs.

Vous pouvez vérifier le statut à tout moment via curl https://hstspreload.org/api/v2/status?domain=captaindns.com.

L'irréversibilité

C'est le point le plus important à comprendre. Une fois dans la preload list, un retrait demande plusieurs mois et ne touche que les versions futures des navigateurs. Les utilisateurs sur une version ancienne continueront de forcer HTTPS sur votre domaine pendant des années. C'est particulièrement gênant dans trois cas :

• Vente de domaine. Si vous cédez captaindns.com à un tiers qui souhaite l'utiliser en HTTP, votre opt-in l'empêchera.
• Décommissionnement d'infrastructure. Si vous arrêtez un service et que le domaine est repris par autre chose, HSTS reste en cache.
• Rollback d'urgence. Si une attaque ou un incident corrompt votre chaîne TLS, vous ne pouvez pas désactiver HTTPS en urgence.

La page hstspreload.org/removal/ documente la procédure de retrait. Elle prévient explicitement que le processus peut prendre plusieurs mois et que certains utilisateurs ne verront jamais le retrait.

Adoption réelle en avril 2026

L'étude APNIC 2023 et les données 2026 montrent que l'adoption reste faible malgré les bénéfices :

Statistique	Valeur
Domaines dans la preload list	~120 000
Taille du fichier embarqué	~18 Mo
Sites ayant HSTS qui activent preload	35,7 %
Top 20 mondial sur preload list	8 sur 20
Adoption finance / banque	Très faible

Google, GitHub, Twitter, Facebook, PayPal figurent dans la liste. En revanche, la moitié des 20 plus gros sites mondiaux n'ont pas HSTS sur leur domaine apex. Les secteurs réglementés (finance, santé) sont en retard, souvent par conservatisme sur la réversibilité.

Guide pas à pas : activer HSTS par stack

Nous couvrons ici les cinq environnements les plus déployés en 2026. Pour chaque stack, la configuration donne d'abord le minimum viable, puis la version éligible preload.

Nginx

Dans Nginx, l'en-tête HSTS est émis via la directive add_header dans le bloc server qui écoute sur le port 443. Le paramètre always est essentiel : sans lui, Nginx n'ajoute l'en-tête que sur les réponses 2xx et 3xx, et l'oublie sur 4xx et 5xx. Un attaquant pourrait alors forcer une erreur 404 pour contourner la protection.

Configuration minimale :

server {
    listen 443 ssl http2;
    server_name captaindns.com;

    ssl_certificate /etc/letsencrypt/live/captaindns.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/captaindns.com/privkey.pem;

    add_header Strict-Transport-Security "max-age=31536000" always;

    # reste de la configuration
}

Configuration éligible preload :

add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

Attention aux blocs imbriqués. Nginx applique add_header uniquement au niveau le plus spécifique qui contient un add_header. Si vous déclarez HSTS au niveau server puis redéclarez un autre add_header dans un bloc location, le HSTS du niveau server disparaît sur cette location. La solution : répéter la directive HSTS dans chaque location ou utiliser more_set_headers du module nginx_headers_more.

Le bloc d'écoute sur le port 80 doit effectuer la redirection 301 vers HTTPS :

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

N'ajoutez jamais l'en-tête HSTS dans ce bloc port 80. Les navigateurs l'ignorent (RFC 6797 §8.1), mais la présence brouille les audits et indique une configuration approximative.

Apache HTTPD

Apache gère HSTS via le module mod_headers. Sur Debian et dérivés, activez-le avec sudo a2enmod headers puis sudo systemctl reload apache2. La directive Header always set écrit l'en-tête sur toutes les réponses, y compris les erreurs.

Configuration minimale dans /etc/apache2/sites-available/captaindns.com.conf ou dans un .htaccess à la racine du site :

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Configuration éligible preload :

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</IfModule>

Comme pour Nginx, l'en-tête doit être placé uniquement dans le VirtualHost qui écoute sur le port 443. Le VirtualHost port 80 doit contenir une redirection vers HTTPS, typiquement via mod_rewrite ou la directive Redirect permanent :

<VirtualHost *:80>
    ServerName captaindns.com
    ServerAlias www.captaindns.com
    Redirect permanent / https://captaindns.com/
</VirtualHost>

Le placement dans .htaccess fonctionne également, ce qui est utile pour les hébergements mutualisés. Il faut néanmoins vérifier que la directive AllowOverride autorise Headers dans la configuration du serveur.

Cloudflare

Cloudflare propose une gestion native de HSTS dans son tableau de bord. Deux avantages : aucune modification de configuration serveur, et Cloudflare sert l'en-tête sur toutes les réponses traversant le CDN, y compris les pages d'erreur gérées côté edge.

Pour activer HSTS sur Cloudflare :

1. Connectez-vous au tableau de bord Cloudflare et sélectionnez le domaine.
2. Allez dans SSL/TLS puis Edge Certificates.
3. Faites défiler jusqu'à HTTP Strict Transport Security (HSTS) et cliquez sur Enable HSTS.
4. Lisez l'avertissement, cochez « I understand », puis Next.
5. Configurez les options :
   • Max Age : choisissez 12 mois minimum (18 mois ou 24 mois pour preload).
   • Apply HSTS policy to subdomains : active includeSubDomains.
   • Preload : active la directive preload.
   • No-Sniff Header : ajoute X-Content-Type-Options: nosniff (recommandé).
6. Cliquez Save.

Cloudflare ajoute immédiatement l'en-tête à toutes les réponses. Vérifiez via curl -I https://captaindns.com que l'en-tête est bien présent.

Attention : Cloudflare sert HSTS même si votre origine est en HTTP derrière Cloudflare. C'est un piège classique : vous pouvez rendre votre site éligible à la preload list alors que l'origine est techniquement insécurisée. Si un jour vous changez de CDN ou passez en DNS Only, les visiteurs tomberont sur une origine HTTP bloquée par HSTS. Avant d'activer preload via Cloudflare, assurez-vous que votre origine est réellement en HTTPS.

AWS CloudFront

CloudFront gère HSTS via les Response Headers Policies, introduites en 2021. Vous pouvez utiliser une policy managée par AWS (Managed-SecurityHeadersPolicy) ou créer une policy custom pour un contrôle fin.

Via la console AWS :

1. CloudFront → Policies → Response headers → Create response headers policy.
2. Section Strict-Transport-Security : activez la case.
3. Renseignez :
   • Max-age (seconds) : 63072000 pour preload, 31536000 sinon.
   • Include subdomains : cochez pour preload.
   • Preload : cochez pour preload.
   • Override origin : cochez pour que CloudFront écrase l'en-tête éventuellement envoyé par l'origine (recommandé).
4. Créez la policy, puis attachez-la à votre distribution CloudFront dans l'onglet Behaviors.

Via Terraform :

resource "aws_cloudfront_response_headers_policy" "security" {
  name = "captaindns-security-headers"

  security_headers_config {
    strict_transport_security {
      access_control_max_age_sec = 63072000
      include_subdomains         = true
      preload                    = true
      override                   = true
    }
  }
}

resource "aws_cloudfront_distribution" "captaindns" {
  # ...
  default_cache_behavior {
    # ...
    response_headers_policy_id = aws_cloudfront_response_headers_policy.security.id
  }
}

L'avantage d'une Response Headers Policy par rapport à une CloudFront Function est le coût : gratuit, pas de facturation par requête.

Caddy

Caddy se distingue : il ne fournit pas HSTS par défaut, volontairement. Matt Holt, son créateur, considère qu'une activation automatique serait dangereuse pour les utilisateurs qui pourraient vouloir retirer HTTPS plus tard.

L'activation manuelle est simple, via la directive header dans le Caddyfile :

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=31536000"
    }

    # reste de la configuration
}

Pour la version preload :

captaindns.com {
    tls admin@captaindns.com

    header {
        Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    }
}

Caddy gère automatiquement la redirection HTTP vers HTTPS, et renouvelle ses certificats Let's Encrypt en arrière-plan. Vous pouvez donc activer HSTS avec confiance dès le jour 1, car Caddy garantit la disponibilité HTTPS sur le long terme.

Pour un reverse proxy, le pattern est identique, mais placez la directive header dans le bloc qui sert le front :

captaindns.com {
    header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    reverse_proxy localhost:3000
}

Procéder au préchargement HSTS

Une fois l'en-tête HSTS stable sur votre domaine apex avec les trois directives, vous pouvez soumettre à la preload list. Ne précipitez pas cette étape : la décision est quasi irréversible.

Checklist avant soumission

Parcourez cette liste. Chaque case doit être cochée.

• Tous les sous-domaines publics (www, api, mail, blog, shop) servent HTTPS avec un certificat valide.
• Tous les sous-domaines internes (staging, admin, monitoring, ci) servent HTTPS ou sont fermés à l'extérieur.
• Le domaine apex sert https:// avec un certificat dont le SAN couvre bien l'apex.
• La redirection HTTP vers HTTPS sur le domaine apex renvoie un 301 (pas un 302).
• L'en-tête HSTS sur l'apex contient max-age=31536000 (ou plus), includeSubDomains et preload.
• La chaîne TLS est complète (aucun certificat intermédiaire manquant).
• Vous n'avez pas de sous-domaine géré par un tiers qui pourrait ne pas supporter HTTPS (ex : un ancien blog en HTTP chez un hébergeur legacy).
• Vous avez vécu au moins 30 jours avec la configuration finale pour capturer les cas limites.

Faites passer le test automatique sur hstspreload.org. Si un voyant rouge apparaît, corrigez avant de soumettre. Les erreurs typiques : certificat auto-signé sur www, redirection 302 au lieu de 301, en-tête HSTS absent sur la réponse 301 du HTTP.

Soumettre le domaine

Une fois le test vert, cliquez sur le bouton de soumission, entrez votre adresse e-mail et confirmez. Le domaine passe en statut pending. Sous 3 à 4 semaines, il est intégré au code source de Chromium. Sous 6 à 12 semaines, il est présent dans les versions stables de Chrome, Firefox, Safari et Edge.

Vous pouvez suivre le statut :

curl "https://hstspreload.org/api/v2/status?domain=captaindns.com"

Les statuts possibles : unknown (inconnu), pending (en attente), preloaded (intégré), rejected (rejeté, voir détails).

Maintenir la politique après soumission

Gardez l'en-tête HSTS avec les trois directives en permanence. Certaines entreprises retirent preload après soumission croyant que c'est fini : c'est une erreur. La présence continue de la directive est vérifiée lors des audits périodiques de la preload list par l'équipe Chromium, et son absence peut entraîner un retrait.

Retirer un domaine (procédure longue)

Si vous devez retirer votre domaine de la preload list :

1. Rendez-vous sur hstspreload.org/removal/.
2. Fournissez les raisons (vente de domaine, migration d'infrastructure, etc.).
3. Servez max-age=0 sur votre domaine pendant la période de retrait.
4. Attendez 4 à 12 semaines pour l'intégration dans Chromium.
5. Attendez 6 à 12 mois supplémentaires pour que la majorité des utilisateurs aient mis à jour leur navigateur.

Pendant cette période, votre domaine reste forcé en HTTPS dans la plupart des navigateurs. Prévoyez la procédure avant de ne plus pouvoir servir TLS.

Erreurs fréquentes et anti-patterns

Activer HSTS sans avoir testé la chaîne HTTPS

C'est l'erreur la plus coûteuse. Activer max-age=31536000 avant d'avoir validé que tous les endpoints servent correctement HTTPS bloque les utilisateurs pour un an. Toujours commencer à max-age=300 et progresser par paliers.

Oublier always dans Nginx

Sans always, add_header n'est émis que sur les réponses 2xx/3xx. Sur une page d'erreur 500 ou 404, l'en-tête HSTS disparaît. Si cette page est la première vue par un nouveau visiteur, la politique n'est pas mémorisée. Un attaquant peut exploiter cette brèche.

Envoyer HSTS sur HTTP

Techniquement, les navigateurs ignorent l'en-tête reçu en HTTP (RFC §8.1). Pratiquement, cela indique une configuration approximative et perturbe les audits. Envoyez HSTS uniquement dans les blocs HTTPS.

Cookies sans attribut Secure

HSTS force HTTPS au niveau navigateur, mais sur un navigateur non compatible ou sur la première visite, un cookie sans Secure peut fuir. Combinez systématiquement HSTS et Set-Cookie: ... ; Secure; HttpOnly; SameSite=Lax.

Preload sans includeSubDomains

Techniquement impossible : le service hstspreload.org refuse toute soumission sans includeSubDomains. Certaines configurations déployées activent preload sans includeSubDomains. Résultat : l'en-tête est servi mais le domaine n'est jamais intégré, ce qui crée une fausse impression de protection.

Certificat auto-signé sur staging

Un développeur se connecte à staging.captaindns.com servi par un certificat auto-signé, puis visite la production captaindns.com. Après activation de HSTS avec includeSubDomains, le développeur ne peut plus accéder à staging : le navigateur refuse le certificat auto-signé. Solution : utilisez un certificat Let's Encrypt via un DNS challenge, ou placez le staging sur un domaine dédié non couvert par la politique.

Redirection 302 au lieu de 301

Le test preload exige un 301 « Moved Permanently » sur la redirection HTTP vers HTTPS. Un 302 « Found » est rejeté. Vérifiez avec curl -I http://captaindns.com.

Absence de HSTS sur la réponse de redirection

Quand le navigateur reçoit la première réponse 301 sur HTTP, il suit la redirection vers HTTPS. C'est la deuxième réponse (sur HTTPS) qui doit contenir HSTS. Certaines configurations, par oubli, placent HSTS sur la redirection HTTP (sans effet) et l'oublient sur la cible HTTPS.

HSTS dans un meta tag HTML

HSTS est un en-tête HTTP, pas un élément HTML. <meta http-equiv="Strict-Transport-Security" content="..."> est ignoré par tous les navigateurs. Toujours envoyer l'en-tête côté serveur.

Oublier de tester après changement d'infrastructure

Après migration vers un nouveau CDN, un changement de reverse proxy ou une mise à jour de Terraform, l'en-tête HSTS peut disparaître silencieusement. Intégrez un test automatisé dans votre CI/CD qui vérifie la présence de l'en-tête sur toutes les routes principales.

Vérifier sa configuration HSTS avec CaptainDNS

Chez CaptainDNS, nous fournissons un outil dédié pour auditer votre configuration HSTS en 3 secondes, sans compte ni inscription : le test HSTS de CaptainDNS.

L'outil effectue trois vérifications en parallèle :

1. Analyse de l'en-tête Strict-Transport-Security : l'outil interroge le domaine en HTTPS, capture l'en-tête et parse ses directives. Il détecte max-age, includeSubDomains, preload, ainsi que les valeurs quotées ou mal formées que certains serveurs renvoient.
2. Interrogation de la preload list de Chrome : via l'API hstspreload.org, il récupère le statut réel de votre domaine (unknown, pending, preloaded, rejected) et l'éligibilité à la soumission.
3. Calcul d'un grade actionnable : le résultat est résumé par un grade parmi cinq niveaux : missing (aucun en-tête), weak (max-age trop faible), good (max-age suffisant), preload-ready (éligible mais non soumis), preloaded (dans la liste Chrome).

Pour chaque grade inférieur à preloaded, l'outil fournit les snippets de configuration prêts à coller pour Nginx, Apache et Cloudflare. Après déploiement du correctif, relancez le test pour confirmer le passage au grade supérieur.

Pour une vue plus large de vos en-têtes de sécurité (CSP, X-Frame-Options, Referrer-Policy, Permissions-Policy), utilisez aussi notre Headers Viewer, qui affiche la liste fidèle des en-têtes dans leur ordre d'arrivée. Pour tester votre redirection HTTP vers HTTPS, le Redirect Checker suit la chaîne complète de redirections.

Si votre objectif va au-delà de HSTS et couvre la sécurité TLS du parc email, consultez notre vérificateur de certificats pour inspecter les certificats TLS ou le check DANE/TLSA pour ajouter une vérification DANE/TLSA sur vos serveurs mail.

FAQ

Qu'est-ce que HSTS, en une phrase ?

HSTS est un en-tête de réponse HTTP qui indique au navigateur de ne contacter un domaine qu'en HTTPS pendant la durée précisée par la directive max-age, ce qui neutralise les attaques qui tentent de forcer une connexion en clair.

Pourquoi mon site marque-t-il « HSTS missing » sur un test ?

Trois causes sont possibles : l'en-tête n'est pas envoyé du tout, il est envoyé uniquement sur HTTP (donc ignoré par les navigateurs), ou il est envoyé sur HTTPS mais avec une syntaxe invalide. Utilisez un outil comme le test HSTS de CaptainDNS pour isoler le problème précis.

Quelle valeur de max-age choisir ?

Pour un rollout prudent, démarrez à max-age=300 (5 minutes), puis montez progressivement par paliers (1 jour, 1 semaine, 1 an). Pour une production stable, max-age=31536000 (1 an) est le minimum recommandé. Pour la preload list, max-age=63072000 (2 ans) est la valeur la plus courante. Au-delà, il n'y a pas de gain de sécurité supplémentaire.

Est-ce que HSTS protège la toute première visite ?

Non. Sans preload list, un navigateur qui visite votre domaine pour la première fois émet une requête HTTP avant de recevoir l'en-tête HSTS. Cette fenêtre de bootstrap reste vulnérable à une attaque man-in-the-middle. La preload list de Chrome résout ce problème en embarquant la liste des domaines connus dans le code source du navigateur.

Puis-je activer HSTS sans includeSubDomains ?

Oui, mais la protection est moins robuste. includeSubDomains couvre notamment les cookies définis au niveau du domaine parent. Sans cette directive, un attaquant peut forcer une requête HTTP vers un sous-domaine non HTTPS pour capturer les cookies. Si tous vos sous-domaines peuvent servir HTTPS, activez-la. Sinon, acceptez une protection partielle.

Que se passe-t-il si je désactive HSTS par erreur ?

Rien de visible côté utilisateur tant que la politique précédemment reçue n'est pas expirée. Le navigateur continue de forcer HTTPS jusqu'à la fin de max-age. Pour désactiver proprement, servez max-age=0 pendant la durée équivalente à votre ancien max-age (au moins 1 an en production stable), puis retirez complètement l'en-tête.

Comment tester HSTS en local sans polluer mon navigateur ?

Utilisez un domaine de test dédié (par exemple un domaine .test réservé par l'IETF ou un second-level domaine distinct de votre production) avec un certificat Let's Encrypt obtenu via DNS challenge. Évitez de tester HSTS sur votre domaine de production depuis votre poste : une mauvaise configuration peut vous bloquer pendant toute la durée de max-age. En développement, vous pouvez aussi purger le cache HSTS de Chrome via chrome://net-internals/#hsts, onglet « Delete domain security policies ».

Faut-il enlever HSTS d'un site qui ne fait plus HTTPS ?

Non, vous ne pouvez pas enlever HSTS simplement. Une fois qu'un navigateur a mémorisé la politique, il refusera toute connexion HTTP jusqu'à expiration de max-age. Avant de migrer un site vers HTTP (ce qui est déconseillé), vous devez servir max-age=0 en HTTPS pendant la durée précédente et attendre l'expiration dans les navigateurs de vos visiteurs.

La preload list est-elle réversible ?

Techniquement oui, pratiquement non. La procédure de retrait sur hstspreload.org prend 4 à 12 semaines pour l'intégration dans Chromium, puis 6 à 12 mois supplémentaires pour que la majorité des utilisateurs aient mis à jour leur navigateur. Certains utilisateurs ne verront jamais le retrait. Avant de soumettre à la preload list, assurez-vous que vous pourrez maintenir HTTPS sur ce domaine pendant des années.

HSTS remplace-t-il la redirection 301 HTTP vers HTTPS ?

Non, il la complète. La redirection 301 est nécessaire pour la toute première visite et pour les utilisateurs qui n'ont jamais reçu l'en-tête HSTS. HSTS prend le relais pour les visites suivantes en convertissant les URL côté navigateur avant l'envoi réseau. Les deux mécanismes doivent coexister.

Combien de sites sont dans la preload list en 2026 ?

Environ 120 000 domaines sont inscrits dans la preload list de Chromium en avril 2026. Le fichier source fait environ 18 Mo. Parmi ces domaines, on trouve la majorité des grands acteurs tech (Google, GitHub, Twitter, Facebook, PayPal) mais seulement la moitié des 20 plus gros sites mondiaux. Les secteurs finance, santé et administration restent très en retard.

Conclusion : HSTS, la base indispensable de toute infrastructure HTTPS

HSTS est la pièce manquante d'une configuration HTTPS robuste. Sans lui, la toute première requête de chaque visite sort en clair sur le réseau, et tout le reste du trafic dépend du bon déroulement de la redirection 301. Avec lui, le navigateur prend le contrôle et convertit localement chaque URL avant même que le résolveur DNS ne soit consulté.

Trois points à retenir :

1. Activez HSTS progressivement. Commencez par max-age=300 pour valider votre chaîne HTTPS, puis montez par paliers sur 2 à 4 semaines. Surveillez les erreurs TLS à chaque palier.
2. Ajoutez includeSubDomains dès que vos sous-domaines sont prêts. Cette directive ferme la porte aux attaques par sous-domaine et protège vos cookies en profondeur. Faites un inventaire exhaustif avant de l'activer.
3. Envisagez la preload list pour la protection maximale. Elle neutralise la vulnérabilité du bootstrap MITM, mais c'est un engagement quasi irréversible. Ne soumettez qu'après 30 jours de stabilité en production.

Pour tester votre configuration HSTS dès maintenant, rendez-vous sur le test HSTS gratuit de CaptainDNS. L'outil calcule votre grade, analyse vos directives, interroge la preload list de Chrome et vous fournit les snippets Nginx, Apache et Cloudflare prêts à coller. Aucun compte requis, résultat en 3 secondes.