Scanner de HSTS faible

Comment fonctionne cette vérification

Cette vérification n'agit que si ton site envoie déjà l'en-tête Strict-Transport-Security ; s'il manque complètement, c'est le scanner d'en-têtes qui le signale. Scanaris lit la valeur et vérifie deux choses : que max-age vaut au moins un an (31536000 secondes) et qu'il inclut includeSubDomains. Si l'une des deux manque, il ouvre un constat de sévérité faible avec le détail. Faible, parce qu'un HSTS court ou partiel protège encore quelque chose ; mais il laisse des trous qu'un attaquant peut exploiter.

Ce que fait HSTS et pourquoi les deux attributs

Quand le navigateur reçoit cet en-tête en HTTPS, il note ton domaine dans une liste interne et, pendant la durée indiquée par max-age, transforme toute tentative d'aller en http:// en https:// avant d'envoyer quoi que ce soit. Ça supprime la première requête non chiffrée qu'une redirection ne peut pas éviter. Un max-age de quelques heures ou jours laisse l'utilisateur sans protection à chaque expiration ; d'où le minimum d'un an. Sans includeSubDomains, un attaquant peut viser nimportequoi.tondomaine.com en HTTP et, par le fonctionnement des cookies de domaine, voler ou fixer des cookies valables pour le site principal.

Comment corriger

La valeur recommandée :

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

• Vercel : le met par défaut sur les domaines personnalisés ; si tu utilises vercel.json ou next.config pour d'autres en-têtes, ajoute-le là avec cette valeur.
• Netlify : dans le fichier _headers, sous /*.
• Nuxt : dans routeRules de nuxt.config, règle '/**'.
• nginx : add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; dans le bloc server du 443.
• Express : helmet.hsts({ maxAge: 31536000, includeSubDomains: true }).

Avant d'ajouter includeSubDomains, confirme que tous tes sous-domaines servent HTTPS : le panneau d'administration, l'API, le blog chez un autre fournisseur, le sous-domaine de messagerie s'il a un site. Tout sous-domaine qui ne répond qu'en HTTP cessera de fonctionner dans les navigateurs qui ont déjà vu l'en-tête, et il n'y a aucun moyen de revenir en arrière avant l'expiration du max-age. En cas de doute, commence avec max-age=86400 et sans sous-domaines, vérifie, puis augmente la valeur quand tout fonctionne.

Preload

Avec preload et un max-age d'au moins un an, tu peux demander l'inclusion de ton domaine dans la liste embarquée par Chrome, Firefox et Safari : ainsi même la première visite ne passe pas par HTTP. C'est la différence habituelle entre un A et un A+ dans les outils d'analyse. Mais c'est un engagement presque irréversible (sortir de la liste prend des mois), donc ne le fais que lorsque tout le domaine est en HTTPS depuis un moment sans incident.

Vérifie que c'est corrigé

curl -sI https://tondomaine.com | grep -i strict-transport

Il doit afficher un max-age de 31536000 ou plus et includeSubDomains. Vérifie sur l'URL publique : si tu as un CDN devant, c'est lui qui doit l'envoyer.

Questions fréquentes

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

Non. L'en-tête n'arrive qu'en HTTPS, donc la première visite a toujours besoin de la redirection. Ils sont complémentaires : la redirection pour la première fois, HSTS pour toutes les autres.

J'ai un sous-domaine interne qui ne passe qu'en HTTP.

Alors ne mets pas includeSubDomains avant de l'avoir migré, et accepte le constat de sévérité faible en attendant. Un sous-domaine non chiffré est un risque réel pour les cookies du domaine, donc la migration en vaut la peine.

Que se passe-t-il si je le configure mal ?

Les navigateurs qui ont reçu l'en-tête garderont la politique jusqu'à son expiration. Tu peux envoyer max-age=0 pour leur demander de l'oublier, mais seuls ceux qui reviennent en HTTPS le verront. C'est pour ça qu'il vaut mieux commencer avec des valeurs courtes.