HSTS (HTTP Strict Transport Security) est un en-tête de sécurité qui indique aux navigateurs de toujours se connecter via HTTPS — même si l’utilisateur tape http:// ou clique sur un lien HTTP. Une fois qu’un navigateur reçoit un en-tête HSTS, il met automatiquement à niveau toutes les futures requêtes vers HTTPS, empêchant les attaques par rétrogradation et les connexions non sécurisées.
Pourquoi HSTS est important
Sans HSTS, la première requête vers votre site peut être en HTTP (avant que la redirection 301 ne s’applique). Pendant cette brève fenêtre, un attaquant sur le réseau peut :
- Supprimer HTTPS — intercepter la redirection et maintenir l’utilisateur en HTTP (attaque par SSL stripping)
- Voler des cookies — si les cookies sont envoyés lors de la requête HTTP initiale
- Injecter du contenu — modifier la réponse de redirection
HSTS élimine cette fenêtre. Après la première visite HTTPS, le navigateur ne tente plus jamais HTTP.
Comment activer HSTS
Nginx
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
Ajoutez ceci dans votre bloc server HTTPS (port 443), pas dans le bloc de redirection HTTP.
Apache
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Nécessite mod_headers (sudo a2enmod headers).
Cloudflare
Dashboard → SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Activer.
Paramètres HSTS
| Paramètre | Exemple | Signification |
|---|---|---|
max-age | 63072000 (2 ans) | Durée (en secondes) pendant laquelle le navigateur se souvient d’utiliser HTTPS |
includeSubDomains | — | Applique HSTS à tous les sous-domaines également |
preload | — | Signale l’intention de rejoindre la liste de preload HSTS |
Choisir max-age
| Phase | max-age | Objectif |
|---|---|---|
| Test | 300 (5 minutes) | Vérifier que HTTPS fonctionne avant de s’engager |
| Confiant | 604800 (1 semaine) | Faible risque en cas de besoin de retour arrière |
| Production | 31536000 (1 an) | Recommandation standard |
| Long terme | 63072000 (2 ans) | Requis pour la liste de preload |
Commencez petit, augmentez progressivement. Si HTTPS tombe en panne alors qu’un long max-age est en cache, les visiteurs ne peuvent plus du tout accéder à votre site — le navigateur refuse de se connecter en HTTP.
HSTS Preload
La liste de preload HSTS est une liste de domaines intégrée en dur dans les navigateurs pour toujours utiliser HTTPS, même lors de la toute première visite (avant de recevoir un quelconque en-tête HSTS).
Conditions requises pour le preload
- Servir un certificat HTTPS valide
- Rediriger HTTP vers HTTPS sur le même hôte
- En-tête HSTS avec
max-age≥ 63072000 (2 ans) - Inclure la directive
includeSubDomains - Inclure la directive
preload
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
Soumettre pour le preload
Rendez-vous sur hstspreload.org, entrez votre domaine et soumettez-le. Après examen (semaines à mois), votre domaine est ajouté aux listes intégrées des navigateurs.
Mises en garde concernant le preload
- C’est difficile à annuler. La suppression de la liste de preload prend des mois et nécessite un cycle de publication de navigateur. Pendant ce temps, votre domaine ne peut être accessible qu’en HTTPS.
includeSubDomainsest obligatoire — chaque sous-domaine doit supporter HTTPS. Sistaging.example.comn’a pas de certificat, il devient inaccessible.- N’activez le preload que si vous êtes certain que tous les sous-domaines actuels et futurs supporteront HTTPS.
Erreurs courantes
Définir HSTS sur la réponse HTTP
HSTS ne doit être envoyé que via HTTPS. Si votre redirection HTTP envoie également l’en-tête HSTS, les navigateurs l’ignorent (la spécification exige HTTPS). Définissez l’en-tête uniquement dans votre bloc port 443.
Oublier les sous-domaines
includeSubDomains applique HSTS à tous les sous-domaines. Si internal.example.com n’a pas HTTPS, il devient inaccessible. Auditez tous les sous-domaines avant d’activer.
Définir un max-age trop élevé trop tôt
Si HTTPS tombe en panne (certificat expiré, erreur de configuration), les visiteurs ne peuvent pas se rabattre sur HTTP. Leur navigateur refuse de se connecter. Commencez avec 5 minutes, vérifiez que tout fonctionne, puis augmentez à 1 an.
Comment vérifier si HSTS est actif
curl -sI https://yourdomain.com | grep -i strict-transport
# Attendu : strict-transport-security: max-age=63072000; includeSubDomains
Dans Chrome DevTools : onglet Réseau → cliquez sur la requête → En-têtes → cherchez Strict-Transport-Security.
Questions fréquentes
HSTS remplace-t-il les redirections HTTP→HTTPS ?
Non. HSTS et les redirections servent des objectifs différents. La redirection intercepte la première requête HTTP. HSTS indique au navigateur de ne plus jamais faire de requêtes HTTP (après la première visite HTTPS). Vous avez besoin des deux.
HSTS peut-il causer des problèmes ?
Oui, si HTTPS tombe en panne. Avec un long max-age, les navigateurs refusent de se connecter en HTTP en solution de repli. C’est pourquoi vous devez commencer avec un max-age court et ne l’augmenter que lorsque HTTPS est stable.
Ai-je besoin de HSTS si je suis sur Cloudflare ?
Cloudflare gère la connexion visiteur→Cloudflare, mais HSTS sur votre serveur d’origine protège la chaîne complète. Activez HSTS via le tableau de bord Cloudflare pour l’edge, et sur votre serveur d’origine si vous utilisez le mode Full (Strict).
Quelle est la différence entre HSTS et la directive CSP upgrade-insecure-requests ?
upgrade-insecure-requests indique au navigateur de charger les sous-ressources (images, scripts) via HTTPS au lieu de HTTP — corrigeant le contenu mixte. HSTS indique au navigateur de toujours utiliser HTTPS pour l’ensemble du domaine. Ils résolvent des problèmes différents et peuvent être utilisés ensemble.