Test HSTS et vérification de la preload list

Pourquoi tester HSTS ?

L'en-tête HSTS est l'un des contrôles de sécurité HTTPS les plus efficaces, mais il est souvent mal configuré : max-age trop court, includeSubDomains oublié, ou domaine éligible à la preload list mais jamais soumis. Tester régulièrement votre configuration permet de détecter ces écarts avant qu'ils ne soient exploités.

Trois cas d'usage principaux :

• Audit de sécurité avant mise en production : valider que la chaîne HTTPS, la redirection HTTP vers HTTPS et l'en-tête Strict-Transport-Security sont cohérents avant d'ouvrir un nouveau domaine au public.
• Préparation à la preload list : vérifier les quatre exigences (max-age supérieur ou égal à 31536000, includeSubDomains, preload, redirection HTTP vers HTTPS) avant de soumettre le domaine à hstspreload.org.
• Vérification post-migration : après un changement d'infrastructure (passage à Cloudflare, migration vers un nouveau cluster Nginx), confirmer que l'en-tête HSTS est toujours envoyé avec les bonnes directives sur la racine et les sous-domaines.

Comment utiliser le test HSTS en 3 étapes

Étape 1 : Saisir le domaine

Tapez le domaine racine sans https:// ni chemin (par exemple captaindns.com). L'outil cible automatiquement la version HTTPS du site et suit la redirection initiale si elle existe. Évitez les sous-domaines en première analyse, sauf si votre objectif est de vérifier un service précis (par exemple api.captaindns.com).

Étape 2 : Lancer le test HSTS

Cliquez sur Tester. CaptainDNS effectue trois actions en parallèle : interrogation de l'en-tête Strict-Transport-Security renvoyé par le serveur, requête à la preload list de Chrome pour confirmer le statut, et analyse des directives max-age, includeSubDomains et preload. Le résultat complet s'affiche en moins de 3 secondes.

Étape 3 : Appliquer les recommandations

Lisez votre grade (missing, weak, good, preload-ready ou preloaded) et la liste des correctifs proposés. Copiez le snippet Nginx, Apache ou Cloudflare adapté à votre stack, déployez-le, puis relancez le test pour confirmer le passage au grade supérieur. Itérez jusqu'à atteindre preloaded si la preload list est votre objectif.

Qu'est-ce que HSTS ?

HSTS (HTTP Strict Transport Security) est un en-tête de réponse HTTP standardisé par la RFC 6797 en 2012. Quand un navigateur reçoit cet en-tête sur une connexion HTTPS valide, il mémorise le domaine et refuse, pour la durée définie, toute connexion en clair vers ce domaine. La conversion http:// vers https:// est faite localement par le navigateur, avant le moindre paquet réseau, ce qui élimine la fenêtre d'interception lors de la première redirection.

L'en-tête se compose de trois directives :

• max-age : durée en secondes pendant laquelle le navigateur applique HSTS. Valeur recommandée pour la production stable : 31536000 (1 an). Pour la preload list : minimum 31536000.
• includeSubDomains : étend la protection à tous les sous-domaines (www, api, mail, etc.). Obligatoire pour la preload list.
• preload : indique le consentement du propriétaire à la soumission du domaine à la preload list de Chrome. Sans cette directive, hstspreload.org refuse la soumission.

Exemple d'en-tête complet :

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

Sans HSTS, un utilisateur qui tape captaindns.com dans la barre d'adresse envoie d'abord une requête HTTP en clair. Un attaquant sur le même réseau Wi-Fi peut intercepter cette requête et servir une version pirate du site (attaque SSL stripping). HSTS rend cette attaque impossible après la première visite légitime, et la preload list la rend impossible dès la première visite pour les domaines préchargés dans le navigateur.

Les 5 grades expliqués

CaptainDNS attribue un grade basé sur les directives détectées et le statut preload. Voici la grille de notation :

Le grade preload-ready ne signifie pas que le domaine est dans la preload list : il indique seulement qu'il remplit les conditions techniques pour y être soumis. La soumission elle-même se fait sur hstspreload.org et l'inclusion dans Chrome prend généralement entre 6 et 12 semaines.

Comment corriger votre configuration HSTS

Voici les snippets prêts à coller pour les trois plateformes les plus courantes. Tous activent un HSTS conforme aux exigences de la preload list.

Nginx

# /etc/nginx/sites-available/captaindns.com
server {
    listen 443 ssl http2;
    server_name captaindns.com;

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

Le mot-clé always garantit que l'en-tête est envoyé même sur les réponses d'erreur (4xx, 5xx). Sans ce mot-clé, une page 404 ne porterait pas l'en-tête HSTS.

Apache (mod_headers)

# /etc/apache2/sites-available/captaindns.com.conf
<VirtualHost *:443>
    ServerName captaindns.com
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>

Activez le module avec a2enmod headers si ce n'est pas déjà fait, puis rechargez Apache.

Cloudflare Workers

addEventListener('fetch', event => {
    event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
    const response = await fetch(request);
    const newHeaders = new Headers(response.headers);
    newHeaders.set(
        'Strict-Transport-Security',
        'max-age=31536000; includeSubDomains; preload'
    );
    return new Response(response.body, {
        status: response.status,
        statusText: response.statusText,
        headers: newHeaders,
    });
}

Sur Cloudflare, vous pouvez aussi activer HSTS depuis le tableau de bord (SSL/TLS, Edge Certificates, HTTP Strict Transport Security) sans déployer un Worker.

Après chaque changement, relancez le test HSTS pour confirmer la prise en compte côté CDN ou reverse proxy.

S'inscrire à la preload list HSTS

La preload list est une liste de domaines codée en dur dans Chrome (et reprise par Firefox, Safari, Edge et Opera). Tout domaine présent dans la liste est traité comme HTTPS-only par les navigateurs, dès la toute première visite, sans même avoir besoin de recevoir l'en-tête HSTS au préalable.

Pour soumettre un domaine sur hstspreload.org, il doit remplir quatre conditions :

• max-age supérieur ou égal à 31536000 (1 an).
• Directive includeSubDomains présente dans l'en-tête.
• Directive preload présente dans l'en-tête.
• Redirection HTTP vers HTTPS active sur le domaine racine et tous les sous-domaines.

Le certificat doit aussi être valide (chaîne complète, non auto-signé, non expiré). Une fois la soumission acceptée, l'inclusion dans Chrome prend en moyenne 6 à 12 semaines, le temps que la modification soit publiée dans une nouvelle version stable du navigateur.

Avertissement sur l'irréversibilité. Le retrait d'un domaine de la preload list est techniquement possible (formulaire de retrait sur hstspreload.org), mais il prend plusieurs mois et ne s'applique qu'aux versions futures de Chrome. Les utilisateurs sur d'anciennes versions continueront de forcer le HTTPS pendant des années. Avant de soumettre, vérifiez que chaque sous-domaine de production, de staging et d'administration interne est accessible en HTTPS, et que vous n'avez pas de plan de migration vers un autre nom de domaine à court terme.

Cas d'usage concrets

Incident 1 : grade weak après audit ANSSI

Symptôme : un audit ANSSI signale que captaindns.com envoie bien un en-tête HSTS, mais que la valeur de max-age (3600) est trop faible pour offrir une protection réelle.

Diagnostic : le test HSTS confirme la présence de l'en-tête Strict-Transport-Security: max-age=3600. Aucune directive includeSubDomains ni preload. Le grade attribué est weak.

Action : modifier la configuration Nginx pour passer à max-age=31536000; includeSubDomains; preload, après avoir validé que tous les sous-domaines (api, mail, status) répondent en HTTPS. Relancer le test : le grade passe à preload-ready.

Incident 2 : sous-domaine cassé après activation includeSubDomains

Symptôme : après l'activation de includeSubDomains sur captaindns.com, l'outil interne metrics.captaindns.com devient inaccessible pour les équipes. Erreur "ERR_SSL_PROTOCOL_ERROR" dans Chrome.

Diagnostic : le sous-domaine metrics ne dispose que d'un endpoint HTTP. La directive includeSubDomains, mémorisée par les navigateurs des équipes, force désormais le HTTPS, mais aucun certificat n'est servi sur ce sous-domaine.

Action : déployer en urgence un certificat Let's Encrypt sur metrics, ou retirer temporairement la directive includeSubDomains et purger le cache HSTS local des équipes (chrome://net-internals/#hsts) le temps de remettre le sous-domaine en conformité.

Incident 3 : domaine preload-ready mais jamais soumis

Symptôme : lors d'un audit de sécurité interne, le test révèle que captaindns.com est preload-ready depuis plus d'un an, mais n'est pas dans la preload list de Chrome. Les nouveaux visiteurs restent vulnérables au SSL stripping lors de la toute première visite.

Diagnostic : la configuration serveur est correcte (max-age=31536000, includeSubDomains, preload, redirection HTTP vers HTTPS). Le statut preload renvoyé par Chrome est "Not in preload list".

Action : soumettre le domaine sur hstspreload.org. Suivre la confirmation, puis attendre 6 à 12 semaines pour la propagation dans la version stable de Chrome. Documenter la décision et son irréversibilité dans le registre interne de sécurité.

FAQ - Questions fréquentes

Q : Qu'est-ce que HSTS ?

R : HSTS (HTTP Strict Transport Security) est un en-tête HTTP de réponse défini par la RFC 6797. Il indique au navigateur de ne contacter le domaine qu'en HTTPS pendant la durée précisée par max-age. Une fois l'en-tête mémorisé, le navigateur convertit toute requête http:// en https:// avant l'envoi, ce qui empêche le downgrade et les attaques SSL stripping sur les réseaux non maîtrisés.

Q : Quelle valeur de max-age choisir pour HSTS ?

R : Pour une mise en production prudente, commencez par max-age=300 (5 minutes) afin de tester sans engagement. Une fois la chaîne HTTPS validée, montez progressivement à 86400 (1 jour) puis 604800 (1 semaine). Pour la preload list, la valeur minimale exigée est 31536000 (1 an), ce qui est aussi la valeur recommandée en production stable. Une valeur plus élevée n'apporte pas de gain supplémentaire.

Q : La preload HSTS est-elle réversible ?

R : Oui, mais en pratique très lentement. Vous pouvez demander le retrait via hstspreload.org, mais l'opération prend plusieurs mois et n'est appliquée qu'aux versions futures de Chrome. Les utilisateurs sur d'anciennes versions continueront de forcer le HTTPS pendant des années. Avant de soumettre un domaine, assurez-vous que toutes les ressources, y compris les sous-domaines internes, sont accessibles en HTTPS.

Q : HSTS fonctionne-t-il sans HTTPS ?

R : Non. La RFC 6797 exige que l'en-tête Strict-Transport-Security soit ignoré quand il est reçu via HTTP. Seules les réponses servies sur une connexion TLS valide peuvent activer HSTS dans le navigateur. Vous devez donc d'abord déployer un certificat valide (Let's Encrypt par exemple) et rediriger tout le trafic HTTP vers HTTPS avant d'envoyer l'en-tête.

Q : HSTS et redirection HTTPS, quelle différence ?

R : Une redirection 301 de HTTP vers HTTPS est exécutée par le serveur après que la requête en clair a quitté le poste. Un attaquant en position de man-in-the-middle peut intercepter cette première requête. HSTS résout ce problème : après la première visite, le navigateur convertit lui-même http:// en https:// avant tout envoi réseau. La redirection reste nécessaire pour la première visite et pour les clients qui n'ont jamais reçu l'en-tête.

Q : Faut-il activer includeSubDomains ?

R : Oui dès que tous les sous-domaines (www, api, mail, admin, intranet, etc.) sont accessibles en HTTPS. La directive includeSubDomains étend la protection HSTS à tout le domaine et est obligatoire pour la preload list. Avant de l'activer, auditez chaque sous-domaine actif : un sous-domaine interne en HTTP (par exemple un outil de monitoring) deviendra inaccessible une fois l'en-tête mémorisé par les navigateurs.

Outils complémentaires

Le test HSTS se combine avec d'autres outils CaptainDNS pour couvrir la sécurité HTTP, DNS et mail :

Ressources utiles

• Guide complet HSTS et preload list (CaptainDNS) (guide de référence pour activer Strict-Transport-Security pas à pas : directives, configurations Nginx, Apache, Cloudflare, AWS, Caddy, soumission preload)
• hstspreload.org (formulaire officiel de soumission à la preload list de Chrome)
• MDN : Strict-Transport-Security (documentation de référence sur l'en-tête HSTS et ses directives)
• RFC 6797 (spécification originale de HTTP Strict Transport Security)
• OWASP HSTS Cheat Sheet (bonnes pratiques de déploiement HSTS)
• content-security-policy.com (guide pratique sur HSTS et exemples de configuration)