HSTS preload

Ce que vérifie ce contrôle

Recherche votre domaine dans la liste HSTS preload de Chromium — une liste statique de domaines HTTPS-only compilée directement dans Chrome, Firefox, Safari, Edge et Brave. Pour les domaines listés, les navigateurs refusent les connexions HTTP en clair dès la toute première requête, avant qu’aucun en-tête n’ait été vu.

Le contrôle renvoie l’un de : preloaded, pending submission, not preloaded ou removal in progress.

Pourquoi c’est important

HSTS ferme la fenêtre d’attaque par downgrade — mais seulement après qu’un navigateur a vu l’en-tête une fois. La toute première visite qu’un utilisateur fait sur votre domaine est encore en clair. Sur un Wi-Fi hostile ou avec un routeur compromis, un attaquant peut intercepter cette première requête, retirer la redirection vers HTTPS et servir une version malicieuse de votre site avant que HSTS ne s’active.

Le preload élimine la fenêtre. Le navigateur sait que votre domaine est HTTPS-only avant que l’utilisateur ne tape l’URL. Même sur une installation toute neuve avec zéro historique, la première requête est chiffrée.

C’est surtout important pour : la banque, la santé, les comptes avec des identifiants de valeur, les flux de paiement et tout site où la première visite pourrait compromettre l’utilisateur. Pour un site marketing sans authentification, le preload est un joli signal de maturité opérationnelle mais pas critique.

Le compromis : le preload est dur à défaire. La suppression prend typiquement 6-12 semaines via le canal stable Chrome, et les utilisateurs sur des versions plus anciennes de navigateur restent verrouillés encore plus longtemps. Ne soumettez que quand vous êtes certain que votre domaine parlera HTTPS pour toujours.

Comment corriger

1. Vérifiez les prérequis avant soumission.

Selon la politique hstspreload.org, votre site doit :

• Servir un certificat HTTPS valide sur le domaine apex et www.
• Rediriger HTTP → HTTPS sur le même hôte (voir redirection HTTP vers HTTPS).
• Envoyer un en-tête HSTS sur chaque réponse HTTPS avec :
  • max-age ≥ 31536000 (un an)
  • includeSubDomains
  • preload
• Servir aussi tous les sous-domaines en HTTPS — includeSubDomains signifie ce qu’il dit.

L’en-tête prêt pour la production :

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

Deux ans est la valeur conventionnelle une fois que vous êtes confiant.

2. Configurez l’en-tête.

nginx :

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

Apache :

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

Cloudflare : SSL/TLS → Edge Certificates → HSTS → réglez max-age à 12+ mois, activez Include subdomains, activez Preload, activez No-Sniff Header.

3. Vérifiez avant de soumettre.

curl -sI https://votredomaine.com | grep -i strict-transport-security
curl -sI https://www.votredomaine.com | grep -i strict-transport-security
curl -sI https://nimportequelsousdomaine.votredomaine.com | grep -i strict-transport-security

Les trois doivent renvoyer l’en-tête avec les trois directives. Si un sous-domaine manque l’en-tête ou sert du non-HTTPS, la soumission sera rejetée.

4. Soumettez sur hstspreload.org.

Entrez le domaine sur hstspreload.org, acceptez les avertissements, cliquez Submit. Le formulaire exécute la même vérification que le contrôle manuel ci-dessus. Les domaines approuvés atterrissent dans la prochaine release Chrome (6-12 semaines jusqu’à stable). Firefox, Safari et Edge tirent depuis la liste Chromium à leur propre cadence.

5. Planifiez le pire avant de soumettre.

Passez en revue ces modes de défaillance et confirmez que chacun est OK :

• Certif expire sans surveillance. Les utilisateurs ont une erreur dure sans fallback HTTP. Automatisez le renouvellement (Let’s Encrypt + timer certbot ou le certif managé de votre fournisseur cloud).
• Sous-domaine a besoin de HTTP (appareil legacy, IoT, outil interne). Ne marchera pas. Vous êtes verrouillé en HTTPS partout pour l’eTLD+1.
• Acquisition / domaine vendu. Le nouveau propriétaire hérite de l’entrée preload jusqu’à ce que la suppression aboutisse. Les acheteurs devraient vérifier la liste preload avant achat.
• Domaine interne soumis par accident. La suppression prend des mois. Ne soumettez que des domaines de production publics.

6. Suppression, si jamais vous en avez besoin.

Soumettez une demande de suppression sur hstspreload.org. Le domaine est retiré à la prochaine mise à jour Chromium (~6 semaines). Les installations de navigateur plus anciennes restent verrouillées aussi longtemps que leur max-age le dit, et les utilisateurs qui ne mettent pas à jour Chrome peuvent être coincés un an ou plus. Baissez le max-age à une petite valeur (par ex. 300) bien à l’avance pour limiter le verrouillage résiduel.

Questions fréquentes

Ai-je besoin du preload si j’ai déjà HSTS ?

Pour la plupart des sites marketing, non. HSTS seul protège tout le monde après leur première visite, ce qui est suffisant quand il n’y a pas d’auth ni de flux de paiement. Le preload importe quand (a) vous traitez des identifiants, de l’argent ou des données de santé, (b) vous pouvez garantir HTTPS pour toujours, et (c) vous avez déjà shippé HSTS pendant au moins quelques mois sans problème.

Combien de temps avant l’apparition effective dans Chrome ?

De la soumission à la première release stable Chrome : typiquement 6-12 semaines. Le formulaire dira « pending » jusqu’à la prochaine compilation de liste, puis « pending preload » pendant qu’il chemine à travers les canaux de release de Chrome (canary → dev → beta → stable). Firefox, Safari et Edge tirent depuis la liste Chromium avec leurs propres cycles de mise à jour — comptez 3-6 mois pour une couverture large.

Puis-je preloader uniquement un sous-domaine, comme app.example.com ?

Oui, mais seulement si l’eTLD+1 parent n’est pas déjà preloadé. Soumettez app.example.com directement. Les mêmes prérequis s’appliquent (en-tête HSTS avec directive preload, HTTPS partout sur ce hostname). C’est la bonne approche quand vous contrôlez un sous-domaine mais ne pouvez pas engager toute l’organisation en HTTPS-pour-toujours.