Qu'est-ce que HSTS (HTTP Strict Transport Security) ?

HTTP Strict Transport Security (HSTS) est un mécanisme de sécurité qui indique aux navigateurs de communiquer avec votre site web uniquement via HTTPS. Une fois que le navigateur a reçu l'en-tête HSTS de votre serveur, il convertit automatiquement toutes les requêtes HTTP en HTTPS pendant la durée spécifiée dans l'en-tête, même si l'utilisateur saisit explicitement http:// dans la barre d'adresse ou clique sur un ancien lien HTTP.

Cela peut sembler n'être qu'une fonctionnalité de confort mineure, mais elle résout un problème réel et dangereux. Voyons précisément pourquoi HSTS existe, comment il fonctionne en pratique, et ce que vous devez savoir en tant que propriétaire d'un site WordPress.

Comment fonctionnent les attaques de SSL Stripping sans HSTS

Imaginez qu'un visiteur ouvre son ordinateur portable dans un café et tape votresite.com dans le navigateur. Sans HSTS, le navigateur envoie d'abord une requête HTTP en clair à votre serveur. Votre serveur répond ensuite par une redirection 301 vers https://votresite.com. Cette requête HTTP initiale est cependant complètement non chiffrée. Elle transite sur le réseau WiFi du café en texte clair.

Un attaquant connecté au même réseau peut intercepter cette première requête non chiffrée à l'aide d'une technique appelée SSL stripping. L'attaquant agit comme un proxy : il maintient une connexion HTTPS vers votre véritable serveur mais sert une version HTTP en clair à la victime. Du point de vue du visiteur, le site semble normal (la plupart des gens ne vérifient pas l'icône du cadenas). Pendant ce temps, l'attaquant peut tout lire : identifiants de connexion, soumissions de formulaires, cookies de session, informations de carte bancaire.

Il ne s'agit pas d'une attaque théorique. Des outils comme sslstrip sont publiquement disponibles depuis 2009, et le SSL stripping reste l'une des attaques les plus pratiques sur les réseaux WiFi publics. HSTS existe précisément pour combler cette faille.

Comment HSTS protège votre site WordPress

Lorsque votre serveur envoie l'en-tête de réponse suivant :

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

Le navigateur stocke cette instruction en interne. Pendant les 31 536 000 secondes suivantes (un an), il ne tentera jamais de connexion HTTP vers votre domaine. Si quoi que ce soit tente de charger une ressource via HTTP, le navigateur la réécrit en HTTPS localement avant même que la requête ne quitte l'appareil. Aucune requête non chiffrée n'est envoyée qu'un attaquant pourrait intercepter.

Cette protection fonctionne au niveau du navigateur, ce qui constitue l'avantage clé. Aucune redirection n'est nécessaire. Aucune requête non chiffrée n'est jamais envoyée. Le navigateur refuse simplement d'utiliser HTTP pour votre domaine.

Les directives de l'en-tête HSTS expliquées

L'en-tête HSTS accepte trois directives, chacune ayant un objectif spécifique :

• max-age : la durée en secondes pendant laquelle le navigateur doit se souvenir d'imposer HTTPS. Les valeurs courantes sont 86400 (1 jour, utile pour les tests initiaux), 2592000 (30 jours, un point de départ raisonnable) et 31536000 (1 an, la valeur recommandée en production). Si vous le réglez à zéro, le navigateur cessera immédiatement d'imposer HSTS pour votre domaine.
• includeSubDomains : étend la politique HSTS à tous les sous-domaines. Cela signifie que cdn.votresite.com, mail.votresite.com et tout autre sous-domaine seront également forcés en HTTPS. Soyez prudent avec cette directive : si l'un des sous-domaines ne prend pas en charge HTTPS, il deviendra inaccessible une fois cette directive active.
• preload : un signal indiquant que vous souhaitez que votre domaine soit ajouté aux listes de préchargement des navigateurs. Plus de détails ci-dessous.

Le problème de la première visite et les listes HSTS Preload

HSTS présente une limitation fondamentale : le navigateur doit recevoir l'en-tête au moins une fois avant de pouvoir imposer quoi que ce soit. Lors de toute première visite, avant que le navigateur n'ait jamais vu votre en-tête HSTS, la requête HTTP initiale reste vulnérable à l'interception. C'est ce que l'on appelle le « problème de la première visite » ou « problème d'amorçage ».

La liste HSTS preload résout ce problème. Il s'agit d'une liste de domaines codée en dur dans le navigateur lui-même (Chrome, Firefox, Safari et Edge partagent tous la même liste). Si votre domaine figure sur la liste de preload, le navigateur impose HTTPS dès la toute première connexion, même si l'utilisateur n'a jamais visité votre site auparavant.

Pour faire ajouter votre domaine à la liste de preload, vous devez remplir toutes les conditions suivantes :

• Servir un certificat HTTPS valide sur votre domaine racine
• Rediriger tout le trafic HTTP vers HTTPS sur le même hôte
• Servir l'en-tête HSTS sur le domaine racine avec une valeur max-age d'au moins 31536000 (un an)
• Inclure la directive includeSubDomains
• Inclure la directive preload
• Tous les sous-domaines doivent prendre en charge HTTPS

Vous pouvez soumettre votre domaine sur hstspreload.org. Gardez à l'esprit que l'inscription à la liste prend des semaines voire des mois (elle est livrée avec les mises à jour des navigateurs), et que le retrait est tout aussi lent. Assurez-vous que votre configuration HTTPS est solide avant de soumettre.

Valeurs courantes de max-age et stratégie de déploiement recommandée

Il est tentant de passer directement à un max-age d'un an, mais un déploiement progressif est plus sûr, en particulier pour les sites comportant plusieurs sous-domaines ou des configurations complexes :

• max-age=300 (5 minutes) : utilisez cette valeur lors des tests initiaux. Si quelque chose tourne mal, les visiteurs ne seront verrouillés en HTTPS que pendant cinq minutes.
• max-age=86400 (1 jour) : une bonne étape suivante une fois que vous avez confirmé que HTTPS fonctionne correctement.
• max-age=2592000 (30 jours) : passez à cette valeur après une ou deux semaines de fonctionnement stable.
• max-age=31536000 (1 an) : la valeur recommandée en production. C'est aussi le minimum requis pour la liste de preload.

Configurer HSTS sur un site WordPress

WordPress n'envoie pas l'en-tête HSTS par défaut. Vous disposez de plusieurs options pour l'ajouter :

L'approche la plus fiable consiste à ajouter l'en-tête au niveau du serveur. Sous Apache, ajoutez ceci à votre fichier .htaccess ou à la configuration de votre hôte virtuel :

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

Pour Nginx, ajoutez ceci dans votre bloc server :

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

Si vous n'avez pas accès à la configuration du serveur (courant sur un hébergement mutualisé), vous pouvez ajouter l'en-tête via PHP dans le fichier functions.php de votre thème ou via une must-use plugin :

add_action('send_headers', function() {
    header('Strict-Transport-Security: max-age=31536000; includeSubDomains; preload');
});

L'approche au niveau du serveur est préférable car elle s'applique à toutes les réponses, y compris les fichiers statiques et les pages d'erreur, et pas seulement aux pages générées par PHP.

Plusieurs extensions de sécurité WordPress proposent également la configuration HSTS via leurs panneaux de réglages, ce qui peut être pratique si vous préférez une approche graphique.

Pièges courants avec HSTS sur WordPress

Avant d'activer HSTS, vérifiez deux fois plusieurs points :

• Contenu mixte : assurez-vous que toutes les ressources (images, scripts, feuilles de style, polices) sont chargées via HTTPS. HSTS force la connexion principale en HTTPS, mais si votre contenu fait encore référence à des URL HTTP, les navigateurs bloqueront ces ressources.
• Renouvellement du certificat SSL : une fois HSTS actif, un certificat expiré rendra votre site complètement inaccessible (au lieu d'afficher un avertissement contournable). Mettez en place le renouvellement automatique des certificats avec Let's Encrypt ou votre fournisseur de certificats.
• Préparation des sous-domaines : si vous utilisez includeSubDomains, chaque sous-domaine doit disposer d'un certificat HTTPS valide. Un sous-domaine de pré-production en HTTP cessera de fonctionner.
• Configuration du CDN : si vous utilisez un CDN comme Cloudflare, assurez-vous que HSTS est configuré de manière cohérente. Cloudflare propose ses propres réglages HSTS qui peuvent remplacer les en-têtes de votre serveur.

Ce que vérifie InspectWP

InspectWP analyse si votre site WordPress envoie l'en-tête de réponse Strict-Transport-Security. Le rapport évalue la valeur max-age, vérifie la présence de la directive includeSubDomains et signale l'absence de l'en-tête s'il n'est pas présent. Un en-tête HSTS correct avec une valeur max-age longue (au moins 6 mois ou un an) et la directive includeSubDomains est recommandé pour tout site WordPress fonctionnant en HTTPS, ce qui devrait être le cas de tous aujourd'hui.