HSTS (HTTP Strict Transport Security) : définition et explications

Le HSTS (HTTP Strict Transport Security) est une politique de sécurité qu’un site déclare avec l’en-tête de réponse Strict-Transport-Security. Dès qu’un navigateur l’a vu sur une connexion HTTPS valide, il refuse d’utiliser le HTTP simple pour cet hôte jusqu’à l’expiration de la politique : les liens http:// saisis sont convertis en interne avant qu’une requête ne quitte l’appareil, et les erreurs de certificat ne peuvent plus être ignorées d’un clic. Le mécanisme est défini dans la RFC 6797.

L’en-tête

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

• max-age : la durée, en secondes, pendant laquelle le navigateur doit mémoriser la politique (31536000 = un an).
• includeSubDomains : applique aussi la politique à tous les sous-domaines.
• preload : signale votre consentement à l’inclusion dans la liste de préchargement intégrée aux navigateurs. Il ne fait pas partie de la RFC ; il est utilisé par la liste de préchargement HSTS, maintenue par le projet Chromium et partagée avec les autres grands navigateurs.

Dans Nginx, envoyez-le uniquement sur les réponses HTTPS :

server {
    listen 443 ssl;
    server_name www.example.com;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Pourquoi c’est important

Sans HSTS, un visiteur qui saisit example.com fait une première requête en HTTP et dépend de votre redirection 301 pour arriver en HTTPS. Sur un réseau hostile, cette première requête non chiffrée peut être interceptée et l’utilisateur maintenu sur une fausse version HTTP : c’est une attaque par SSL stripping. Le HSTS comble cette faille pour les visiteurs récurrents, et la liste de préchargement la comble aussi pour les premières visites.

Il y a un avantage de performance : pour les navigateurs compatibles HSTS, le saut HTTP vers HTTPS disparaît, car le navigateur convertit lui-même l’URL (les outils de développement l’affichent comme une redirection 307 interne). Le HSTS n’est pas un facteur de classement, mais il complète une configuration HTTPS propre, que Google et les utilisateurs attendent déjà.

Le déployer sans risque

1. Vérifiez que chaque page et chaque sous-domaine fonctionne en HTTPS avec un certificat valide.
2. Commencez par un max-age court, par exemple 300 secondes, et surveillez les problèmes.
3. Augmentez à une semaine, un mois, puis un an.
4. N’ajoutez includeSubDomains qu’une fois que tous les sous-domaines, y compris les anciens hôtes de préproduction, la messagerie et les outils d’intranet, prennent en charge le HTTPS.
5. Demandez le préchargement en dernier, et seulement si vous êtes certain. La liste de préchargement exige un max-age d’au moins un an, includeSubDomains et preload, et un retrait met des mois à atteindre les navigateurs des utilisateurs.

Erreurs courantes

• Envoyer l’en-tête en HTTP, où les navigateurs l’ignorent par conception.
• Précharger un domaine alors qu’il existe encore un sous-domaine en HTTP seul, qui devient alors inaccessible dans les navigateurs.
• Définir un max-age long avant que le HTTPS soit stable, ce qui bloque l’accès des visiteurs si le certificat se casse.
• Supposer que le HSTS remplace la redirection côté serveur. Conservez la redirection pour les nouveaux visiteurs, les robots et les clients qui ne prennent pas en charge le HSTS.

Comment vérifier

Le En-têtes de sécurité note votre en-tête Strict-Transport-Security avec les autres en-têtes de sécurité, et fournit des corrections à copier-coller pour Apache, Nginx et Cloudflare. Le Vérificateur SSL confirme le certificat et la redirection HTTP vers HTTPS dont dépend le HSTS.

Questions fréquentes