Comment configurer HSTS sans vous exclure

HSTS est simple, jusqu’à ce qu’il ne le soit plus

HTTP Strict Transport Security, généralement abrégé en HSTS, indique aux navigateurs : « pour ce site, utilisez toujours HTTPS ». Une fois qu’un navigateur reçoit l’en-tête via une connexion HTTPS valide, il mémorise la règle pour la durée que vous spécifiez.

C’est utile. Cela empêche les attaques par rétrogradation de protocole, réduit les requêtes non sécurisées accidentelles et évite ce moment gênant où un utilisateur saisit example.com et passe brièvement par HTTP en clair avant d’être redirigé.

C’est aussi persistant. Si vous publiez la mauvaise politique HSTS, les navigateurs peuvent continuer à l’appliquer longtemps après que vous avez retiré l’en-tête de votre serveur. C’est ainsi que des équipes se retrouvent bloquées : pas exactement hors de leur propre panneau d’administration, mais hors des navigateurs des utilisateurs, des sous-domaines, des systèmes de staging, des endpoints hérités et des services oubliés qui ne sont pas prêts pour HTTPS forcé.

L’objectif n’est pas d’éviter HSTS. L’objectif est de le déployer comme une migration, pas comme un interrupteur.

Ce que fait réellement l’en-tête HSTS

Un en-tête HSTS typique ressemble à ceci :

Strict-Transport-Security: max-age=31536000; includeSubDomains

Il comporte trois parties importantes :

• max-age : la durée, en secondes, pendant laquelle le navigateur doit imposer HTTPS pour cet hôte.
• includeSubDomains : indique si la règle s’applique aussi à chaque sous-domaine.
• preload : un signal indiquant que vous souhaitez inclure le domaine dans les listes de preload des navigateurs.

Le navigateur ne fait confiance à cet en-tête que lorsqu’il le reçoit via HTTPS valide. Si le certificat est invalide, expiré ou ne correspond pas, le navigateur ne devrait pas accepter de nouvelle politique HSTS depuis cette réponse.

Une fois la politique stockée, les futures tentatives de visite de http://example.com sont mises à niveau par le navigateur vers https://example.com avant l’envoi de la requête. C’est le gain de confidentialité : la requête non sécurisée ne quitte jamais l’appareil.

Les scénarios de blocage à éviter

La plupart des échecs HSTS ne sont pas causés par le site principal. Ils se produisent aux marges.

1. Un sous-domaine oublié n’est pas prêt pour HTTPS

includeSubDomains semble propre, mais il est absolu. Si vous le définissez sur example.com, il s’applique à :

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• tout autre élément sous ce domaine

Si l’un de ces hôtes ne peut pas servir un HTTPS valide, les utilisateurs ayant la politique HSTS en cache ne pourront pas y accéder via HTTP.

2. Un certificat expire

Sans HSTS, les utilisateurs cliquent parfois malgré les avertissements de certificat. Ce n’est pas une bonne pratique de sécurité, mais cela arrive.

Avec HSTS, les navigateurs modernes ne permettent pas de contourner facilement les erreurs de certificat pour cet hôte. C’est précisément le but. Cela signifie aussi que le renouvellement des certificats doit être banal, surveillé et testé.

3. Les outils de staging ou internes vivent sous le domaine de production

Placer des outils internes sous *.example.com peut devenir douloureux dès que le domaine parent utilise includeSubDomains. Si ces outils utilisent des certificats auto-signés, des autorités de certification privées, d’anciennes configurations TLS ou pas de HTTPS du tout, HSTS exposera le raccourci.

C’est l’une des raisons pour lesquelles de nombreuses équipes gardent les systèmes internes et expérimentaux sous un domaine distinct ayant sa propre politique de sécurité.

4. Le preload est traité comme une case à cocher de routine

Le preload HSTS n’est pas simplement une directive de plus. Cela signifie que votre domaine peut être livré dans les navigateurs comme HTTPS-only avant même qu’un utilisateur ait visité votre site.

Cela comble l’écart de la « première visite », mais c’est beaucoup plus difficile à annuler. Le retrait des listes de preload peut prendre des semaines ou des mois avant d’atteindre les utilisateurs, selon les cycles de publication des navigateurs. Le preload convient aux domaines stables et matures. Il ne convient pas à un site qui est encore en train de découvrir son inventaire de sous-domaines.

Un plan de déploiement sûr

Étape 1 : Auditez chaque nom d’hôte que vous contrôlez

Avant de définir includeSubDomains, listez chaque nom d’hôte sous le domaine. Les enregistrements DNS sont un point de départ, mais pas toute l’histoire. Vérifiez les configurations CDN, les tableaux de bord d’hébergement, les noms d’hôte liés à l’e-mail, les anciens outils marketing, les buckets de stockage et la documentation interne.

Pour chaque nom d’hôte, répondez :

• Sert-il HTTP, HTTPS ou les deux ?
• Le certificat HTTPS est-il valide et renouvelé automatiquement ?
• Redirige-t-il HTTP vers HTTPS proprement ?
• Est-il censé être public ?
• Est-il encore nécessaire ?

Si votre équipe a déjà des habitudes de débogage des en-têtes de production, cela s’intègre naturellement aux côtés des vérifications de redirections et d’en-têtes. Nous avons couvert ce flux de travail dans une petite boîte à outils pour déboguer les redirections et les en-têtes HTTP en production.

Étape 2 : Corrigez HTTPS avant d’ajouter HSTS

HSTS ne rend pas sécurisée une configuration HTTPS cassée. Il ne fait que rendre HTTPS obligatoire.

Avant de l’activer, vérifiez :

• Les certificats TLS couvrent les bons noms d’hôte.
• Les certificats se renouvellent automatiquement.
• HTTP redirige vers HTTPS avec un seul saut propre lorsque c’est possible.
• Les redirections d’hôte canonique sont cohérentes, par exemple de non-www vers www, ou l’inverse.
• Les assets de l’application ne dépendent pas d’URL http:// non sécurisées.

Le contenu mixte est moins courant qu’auparavant, mais il apparaît encore dans les anciens thèmes CMS, les snippets d’analytics, les médias intégrés et les chemins d’images codés en dur.

Étape 3 : Commencez avec un max-age très court

Ne commencez pas avec un an. Commencez avec cinq minutes :

Strict-Transport-Security: max-age=300

Déployez cela uniquement sur le nom d’hôte que vous testez, généralement le site de production canonique. Omettez includeSubDomains pour l’instant.

Testez ensuite dans de vrais navigateurs et avec des requêtes en ligne de commande :

curl -I https://example.com

Vous devriez voir exactement un en-tête Strict-Transport-Security. Les en-têtes HSTS dupliqués provenant d’un serveur applicatif et d’un CDN sont une source courante de confusion. Les navigateurs appliquent généralement la politique effective, mais les humains qui déboguent un incident n’ont pas besoin d’ambiguïté.

Étape 4 : Augmentez progressivement

Si rien ne casse, augmentez la durée par étapes :

Strict-Transport-Security: max-age=86400

Puis :

Strict-Transport-Security: max-age=604800

Puis peut-être :

Strict-Transport-Security: max-age=2592000

Un calendrier pratique est :

• 5 minutes
• 1 jour
• 1 semaine
• 1 mois
• 6 mois ou 1 an

Il n’y a aucun prix à gagner en se précipitant. Tout l’intérêt d’un déploiement progressif est de donner à votre monitoring, à votre boîte de support et aux cas limites le temps de vous signaler ce que votre checklist a manqué.

Étape 5 : N’ajoutez includeSubDomains qu’après un véritable audit

Une fois que chaque sous-domaine public est prêt pour HTTPS, vous pouvez envisager :

Strict-Transport-Security: max-age=31536000; includeSubDomains

C’est le moment d’être conservateur. Si un service hérité a encore besoin de HTTP, n’ajoutez pas includeSubDomains au domaine parent. Migrez ce service, déplacez-le vers un autre domaine ou acceptez que votre politique HSTS doive rester plus étroite pour l’instant.

Les en-têtes de sécurité doivent refléter la réalité. Ils ne doivent pas être utilisés comme affiches de motivation pour une infrastructure que vous espérez avoir plus tard.

Étape 6 : Traitez le preload comme un projet distinct

N’envisagez le preload que lorsque toutes les conditions suivantes sont vraies :

• Le domaine et tous les sous-domaines prennent en charge HTTPS valide.
• HTTP redirige vers HTTPS.
• L’en-tête HSTS utilise un max-age d’au moins 31536000 secondes.
• L’en-tête inclut includeSubDomains.
• L’en-tête inclut preload.
• Vous êtes certain de ne pas avoir besoin de HTTP en clair nulle part sous le domaine.

Un en-tête prêt pour le preload ressemble à ceci :

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

La soumission à la liste de preload est un engagement à long terme. Si le site est un microsite de campagne, un domaine produit temporaire ou un domaine dont les frontières de propriété sont floues, passez votre tour.

Exemples de configuration

Nginx

Utilisez always afin que l’en-tête soit aussi envoyé sur les réponses d’erreur :

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

Une fois le déploiement stable :

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

Apache

Avec mod_headers activé :

Header always set Strict-Transport-Security "max-age=300"

Plus tard :

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

CDN ou plateforme edge

Si votre CDN définit les en-têtes de réponse, préférez gérer HSTS à un seul endroit. Ne définissez pas une politique à l’origine et une autre à l’edge, sauf si vous avez une raison très claire.

Vérifiez aussi si le CDN applique les en-têtes aux redirections, aux erreurs mises en cache et aux pages d’erreur personnalisées. Un site de production ne se résume pas à sa réponse 200 OK.

Comment annuler HSTS en toute sécurité

Si vous devez désactiver HSTS, envoyez :

Strict-Transport-Security: max-age=0

Mais il y a un piège : le navigateur doit réussir à atteindre le site via HTTPS valide pour recevoir cet en-tête. Si HTTPS lui-même est cassé, les utilisateurs ayant une politique HSTS en cache ne peuvent pas récupérer l’instruction qui l’effacerait.

L’ordre de récupération habituel est donc :

1. Rétablir HTTPS valide.
2. Servir Strict-Transport-Security: max-age=0.
3. Le maintenir en place assez longtemps pour que les utilisateurs qui reviennent le reçoivent.
4. Retirer ou remplacer l’en-tête une fois l’incident résolu.

Si le domaine est préchargé, servir max-age=0 ne suffit pas pour les nouveaux profils de navigateur. Vous devez aussi demander le retrait de la liste de preload et attendre que ce changement soit livré via les mises à jour des navigateurs.

Checklist de test avant la mise en production

Utilisez cette checklist avant d’augmenter max-age ou d’ajouter includeSubDomains :

• L’URL HTTPS canonique renvoie un certificat valide.
• HTTP redirige vers HTTPS.
• Il n’y a qu’un seul en-tête HSTS.
• L’en-tête apparaît sur les redirections et les réponses d’erreur lorsque c’est approprié.
• Tous les sous-domaines publics ont un HTTPS valide.
• Le renouvellement des certificats est surveillé.
• Aucun système interne critique ne dépend de HTTP sous le même domaine parent.
• Le preload a été discuté explicitement, et non ajouté par habitude.

Lighthouse peut aussi signaler des en-têtes de sécurité manquants ou faibles dans certains contextes, mais il ne doit pas être votre seule méthode de vérification. Si vous l’utilisez dans le cadre d’une revue plus large, lisez les résultats comme des signaux plutôt que comme des verdicts ; le même état d’esprit s’applique lorsque vous lisez un rapport Lighthouse sans paniquer.

<!-- tool-cta:start -->

💡 Essayez ceci : Avant et après chaque modification HSTS, inspectez la réponse Strict-Transport-Security avec Get Headers afin de confirmer que max-age, includeSubDomains et preload correspondent à ce que vous attendez.

<!-- tool-cta:end -->

L’argument de confidentialité en faveur de HSTS

HSTS est souvent présenté comme un en-tête de sécurité, et c’en est un. Il offre aussi un bénéfice de confidentialité : il réduit la probabilité que la première requête d’un utilisateur fuie en HTTP en clair sur un réseau non fiable.

C’est important sur le Wi-Fi d’aéroport, les réseaux d’hôtel, les réseaux invités d’entreprise et partout où le trafic d’un utilisateur pourrait être observé ou modifié. Une requête HTTP en clair peut exposer le nom d’hôte, le chemin, les cookies sans l’attribut Secure et d’autres détails de la requête. HTTPS n’est pas magique, mais l’imposer systématiquement supprime toute une classe de fuites évitables.

Les meilleurs déploiements HSTS sont sans histoire. Ils sont déployés lentement, soutenus par des certificats fiables et suffisamment ennuyeux pour que personne ne les remarque. C’est exactement ce que vous attendez d’un en-tête dont le mode de défaillance peut être spectaculaire.