Table des matières de l'article :
HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité Web qui permet aux sites Web de se déclarer accessibles uniquement via des connexions sécurisées. Cela permet de protéger les sites Web et les utilisateurs contre les déclassements de protocole et les attaques de piratage de cookies.
HTTP Strict Transport Security (HSTS) a une histoire fascinante qui remonte à 2008. Tout a commencé avec un document de recherche intitulé "HTTPS forcé : protection des sites Web hautement sécurisés contre les attaques réseau», écrit par Collin Jackson et Adam Barth. Ce travail révolutionnaire a jeté les bases de ce qui allait devenir HSTS, décrivant l'idée fondamentale de forcer les connexions de sites Web à utiliser HTTPS pour améliorer la sécurité.
Puis, le 18 septembre 2009, une évolution significative a eu lieu lorsque PayPal, avec Jackson et Barth, a publié une version révisée du schéma de protocole contenu dans le document original. Ce document mis à jour, qui est disponible en ligne, a été un pas en avant dans la définition de ce qui allait devenir le HSTS.
La prochaine phase cruciale de l'histoire du HSTS s'est produite le 18 décembre 2009, lorsque la dernière « version communautaire » de la spécification alors nommée « STS » a été publiée. Cette version a incorporé des modifications basées sur les commentaires reçus de la communauté de la sécurité Internet, affinant davantage les directives d'utilisation du HSTS.
Enfin, la spécification formelle du HSTS (RFC 6797) a été publiée le 19 novembre 2012, après avoir été approuvée le 2 octobre 2012 par l'Internet Engineering Steering Group (IESG), un organe composé du président de l'Internet Engineering Task Force ( IETF) et par les différents directeurs de zone. Cette approbation a marqué l'officialisation du HSTS comme norme de sécurité pour les connexions aux sites Web, confirmant son rôle clé dans la protection des utilisateurs contre diverses attaques de réseau.
Pourquoi le HSTS a-t-il été introduit ?
Le protocole HTTP (Hypertext Transfer Protocol) est un protocole de communication largement utilisé pour la transmission d'informations sur Internet. Ce protocole s'appuie sur différents systèmes de transport, dont le plus courant est le Transmission Control Protocol (TCP). TCP est le pilier fondamental du système de transport et assure la livraison fiable des données entre les systèmes interconnectés.
Cependant, TCP présente un défaut important : il n'offre aucune protection de l'intégrité des données, de la confidentialité des informations ou de l'identification sécurisée de l'hôte. En d'autres termes, les informations transmises via TCP sont vulnérables à l'interception non autorisée, à la modification des données et à la fausse identification.
Ce manque de sécurité a motivé la création de protocoles supplémentaires pour améliorer la sécurité des données lors de leur transmission. Secure Sockets Layer (SSL) et son successeur, Transport Layer Security (TLS), sont nés avec cet objectif. Ces protocoles fournissent une couche de cryptage qui agit comme un bouclier entre les protocoles d'application et TCP. L'utilisation combinée de HTTP et de SSL/TLS donne naissance à ce que nous appelons communément HTTPS, ou HTTP sécurisé.
Les agents utilisateurs, comme les navigateurs Web, utilisent diverses politiques de sécurité locales pour décider comment interagir avec un hôte. Cette décision est basée sur un certain nombre de facteurs, notamment la négociation entre le serveur et l'agent utilisateur, les préférences de l'utilisateur et la méthode de communication utilisée (HTTP ou HTTPS).
Cependant, dans certaines circonstances, les utilisateurs peuvent choisir de continuer à interagir avec un site Web même s'ils ne sont pas en mesure d'établir une connexion sécurisée. Cela peut se produire lorsque la chaîne de confiance d'un certificat TLS n'est pas validée, lorsque le certificat a expiré ou lorsque le nom de domaine de l'hôte TLS s'affiche de manière incorrecte dans le certificat. Cette pratique est connue sous le nom d'"insécurité du clic".
Bien que cette possibilité puisse sembler pratique pour l'utilisateur, elle introduit des risques de sécurité potentiels. Les utilisateurs qui décident de continuer à utiliser un site Web sans connexion HTTPS sécurisée deviennent vulnérables à divers types de cyberattaques. Parmi celles-ci, les plus importantes sont les attaques de l'homme du milieu (MITM), dans lesquelles un attaquant intercepte et altère potentiellement la communication entre deux parties, les attaques de rétrogradation, qui forcent une connexion à utiliser un protocole moins sécurisé, et le détournement de session, dans lequel un attaquant prend le contrôle de la session d'un utilisateur.
Suppression SSL
HTTP Strict Transport Security (HSTS) est un mécanisme de sécurité qui permet aux sites Web d'indiquer qu'ils ne sont accessibles que via une connexion sécurisée. Cela signifie qu'un site Web peut empêcher les utilisateurs de s'y connecter via des connexions non sécurisées, telles que celles basées sur le protocole HTTP. Cette mesure protège efficacement les utilisateurs d'une vulnérabilité de sécurité bien connue appelée SSL-stripping.
Le SSL stripping est un type d'attaque par downgrade, une forme particulièrement insidieuse d'attaque cryptographique sur un système informatique ou, comme dans ce cas, un protocole de communication. L'attaque de rétrogradation force le système ou le protocole à abandonner sa connexion cryptée (HTTPS) et à adopter à la place une ancienne connexion non cryptée (HTTP), qui est généralement maintenue en place pour une compatibilité descendante avec les systèmes plus anciens.
Le décapage SSL a été présenté pour la première fois par Moxie Marlinspike dans son discours à la conférence BlackHat 2009, intitulé "Nouveaux trucs pour vaincre SSL en pratique". Cette attaque est mise en œuvre dans le cadre d'une attaque de l'homme du milieu, où le trafic Web est intercepté et détourné de la version HTTPS sécurisée du site Web vers une version HTTP non chiffrée.
Un facteur majeur qui permet à ce type d'attaque de continuer à réussir est que de nombreux sites Web n'utilisent pas de certificats TLS/SSL. Par conséquent, il est impossible de déterminer (sans connaissance préalable) si l'absence de HTTPS d'un site Web est due à une attaque SSL stripping ou parce que le site ne possède pas de certificat TLS.
Un aspect particulièrement alarmant de cette attaque est qu'il n'y a pas de signaux ou d'avertissements qui peuvent avertir l'utilisateur pendant le processus de rétrogradation. Cela rend l'attaque difficile à détecter, même pour l'utilisateur le plus attentif et le plus conscient de la sécurité.
La création par Marlinspike d'un outil pour automatiser entièrement ce type d'attaque fait du SSL stripping un risque sérieux pour la cybersécurité. La menace posée par ces attaques souligne l'importance de prendre des mesures de sécurité appropriées, telles que l'utilisation du HSTS, pour garantir l'intégrité et la sécurité des communications en ligne.
Détournement de session - Détournement de session
Le piratage de session, également appelé piratage de session ou piratage de cookies, est un type de vulnérabilité de sécurité qui peut être exploitée par l'insécurité des clics, un comportement qui permet aux utilisateurs de continuer à interagir avec un site Web malgré l'absence de connexion HTTPS sécurisée.
Dans une attaque de détournement de session, un attaquant exploite une session valide entre un ordinateur et un serveur pour obtenir un accès non autorisé à des informations ou à des services. Ce type d'attaque est particulièrement pertinent pour les développeurs Web, car les cookies, de petits fichiers texte enregistrés sur l'appareil de l'utilisateur, sont utilisés pour maintenir l'état de la session sur de nombreux sites Web.
Si un site Web ne marque pas ses cookies comme sécurisés, en demandant aux agents utilisateurs, tels que les navigateurs Web, d'envoyer des cookies uniquement via une connexion HTTPS, ils peuvent facilement être interceptés et volés par un attaquant. En effet, des cookies non sécurisés sont envoyés à l'hébergeur quelle que soit la sécurité du canal de transport utilisé, ce qui les rend vulnérables aux attaques de l'homme du milieu. Ces attaques se produisent lorsqu'un attaquant parvient à intercepter et potentiellement à manipuler la communication entre deux parties sans que l'une ou l'autre des parties en soit consciente.
Une fois qu'un attaquant a eu accès aux cookies, il peut se faire passer pour l'utilisateur d'origine sur un site Web légitime, en utilisant les informations d'identification de session enregistrées dans le cookie pour accéder aux ressources protégées du site comme s'il était l'utilisateur légitime. Ce type d'attaque peut avoir de graves conséquences, notamment l'accès non autorisé à vos informations personnelles, financières ou sensibles.
Il est important de noter qu'afin d'empêcher le détournement de session, il est essentiel que les sites Web utilisent des connexions HTTPS sécurisées et marquent leurs cookies comme sécurisés afin qu'ils ne soient envoyés que sur des connexions cryptées. En outre, les utilisateurs doivent être conscients des risques associés aux clics non sécurisés et doivent éviter d'accepter des connexions non sécurisées dans la mesure du possible.
Comment fonctionne le HSTS ?
HTTP Strict Transport Security (HSTS) est un protocole de sécurité qui permet aux serveurs Web de déclarer que toutes les interactions entre un navigateur Web ou d'autres programmes utilisateur doivent se produire via des connexions HTTPS, qui offrent un cryptage sécurisé, au lieu de connexions HTTP non sécurisées.
Un serveur peut implémenter une stratégie HSTS en fournissant un en-tête de réponse spécifique via une connexion HTTPS. Cet en-tête, appelé Strict-Transport-Security, spécifie une période de temps pendant laquelle l'interpréteur, tel qu'un navigateur Web, doit accéder au service exclusivement via des requêtes HTTPS. Il est important de noter que les en-têtes HSTS envoyés via des réponses HTTP non sécurisées sont ignorés pour éviter la possibilité d'une manipulation malveillante.
Le fonctionnement de HSTS est relativement simple. La première fois qu'un utilisateur accède à un site via HTTPS et que le site renvoie l'en-tête Strict-Transport-Security, le navigateur enregistre ces informations. Ensuite, les futures tentatives de chargement du site via HTTP seront automatiquement redirigées vers HTTPS, assurant ainsi une connexion sécurisée.
Une fois que le temps spécifié par l'en-tête Strict-Transport-Security s'est écoulé, la prochaine tentative de chargement du site via HTTP se déroulera comme d'habitude, au lieu d'être automatiquement redirigé vers HTTPS. Cependant, chaque fois que l'en-tête Strict-Transport-Security est fourni à l'agent utilisateur, il met à jour la période de validité de ce site. Par conséquent, les sites peuvent continuer à envoyer ces en-têtes pour empêcher l'expiration de la politique HSTS.
S'il est nécessaire de désactiver HSTS, les serveurs Web peuvent définir la valeur d'âge maximale sur zéro sur une connexion HTTPS. Cela fera immédiatement expirer l'en-tête HSTS, permettant ainsi l'accès via des requêtes HTTP.
Un exemple du fonctionnement de HSTS serait un serveur envoyant un en-tête demandant que toutes les demandes futures pour l'année prochaine utilisent uniquement HTTPS. Cela peut être accompli via l'en-tête Strict-Transport-Security : max-age=31536000.
Lorsqu'une application Web envoie une politique HSTS aux agents utilisateurs, les agents utilisateurs conformes remplacent automatiquement toutes les connexions non sécurisées par des connexions sécurisées. Par exemple, un lien comme http://example.com/ serait transformé en https://example.com avant d'atteindre le serveur. De plus, si une connexion sécurisée ne peut pas être établie, par exemple parce que le serveur ne dispose pas d'un certificat valide, l'agent utilisateur interrompra la connexion et ne permettra pas à l'utilisateur d'accéder au site Web.
L'aspect le plus important du HSTS est qu'il empêche les clics non sécurisés en ne permettant pas à l'utilisateur d'utiliser la connexion non sécurisée. Il s'agit de protéger les utilisateurs contre divers types de cyberattaques, telles que les attaques de l'homme du milieu, les attaques de rétrogradation et les détournements de session.
Quel est un exemple de situation impliquant le HSTS ?
Prenons un exemple pratique qui illustre l'importance et l'efficacité de HTTP Strict Transport Security (HSTS). Imaginons qu'un membre de votre équipe décide d'utiliser un point d'accès Wi-Fi gratuit dans un café pour surfer sur le Web. Au cours de sa session de navigation, il décide de se connecter au système de paie de votre organisation pour vérifier ses détails salariaux.
Malheureusement, le point d'accès Wi-Fi auquel vous vous êtes connecté n'est pas sécurisé. Il est géré par un pirate informatique qui a configuré son ordinateur portable pour intercepter les requêtes HTTP en transit. Lorsque votre employé essaie d'accéder à votre système de paie, le pirate intercepte la requête HTTP d'origine et redirige votre employé vers un faux site Web, une copie parfaite de votre système de paie. Cela conduit à l'exposition des informations personnellement identifiables (PII) de vos employés, ce qui crée un problème important de confidentialité et de sécurité.
Cependant, si votre système de paie utilise HSTS et que votre employé a déjà visité le site en utilisant une connexion HTTPS, son navigateur se souviendra d'utiliser uniquement les connexions HTTPS pour ce site à l'avenir. Cela signifie que peu importe à quel point le pirate essaie de rediriger le trafic de votre employé vers un faux site Web via une connexion HTTP non sécurisée, le navigateur de l'employé insistera pour utiliser uniquement HTTPS.
De cette manière, l'utilisation du HSTS protège efficacement vos employés et votre système de paie contre les attaques potentielles de l'homme du milieu. Démontrant à quel point il est crucial pour les organisations de s'assurer que leurs sites Web implémentent correctement le protocole HSTS, afin de maintenir la sécurité et la confidentialité de leurs utilisateurs et de leurs données.
Quelles sont les limites du HSTS ?
HTTP Strict Transport Security (HSTS) est un outil puissant pour sécuriser les connexions Web, mais il présente également certaines limitations fondamentales.
La première est qu'un utilisateur incapable d'établir une connexion HTTPS sécurisée ne pourra pas accéder au site Web qui implémente HSTS. Cela peut créer des problèmes d'accessibilité dans des circonstances où les connexions HTTPS sont problématiques ou indisponibles.
De plus, la communication de la politique HSTS se fait via un en-tête de réponse HTTP, ce qui signifie que l'utilisateur doit d'abord visiter le site Web pour découvrir qu'il utilise HSTS. Cela implique que la première demande au site Web, si elle est effectuée via un protocole non sécurisé tel que HTTP, reste vulnérable aux attaques actives. Il en va de même pour la première réclamation après l'expiration de la période spécifiée dans la directive HSTS "max-age". Cette période est généralement définie sur plusieurs jours ou mois, en fonction des besoins spécifiques du site et du comportement des utilisateurs.
Pour atténuer ce problème, de nombreux navigateurs prennent en charge les stratégies HSTS de "préchargement". Cela signifie qu'ils maintiennent une liste de sites Web connus pour utiliser HSTS et utilisent automatiquement une connexion HTTPS pour la première requête vers ces sites. Cependant, cette approche ne s'applique pas à l'ensemble du Web. Il y a eu des discussions sur l'utilisation des enregistrements DNS et DNSSEC pour déclarer et garantir l'utilisation du HSTS, qui peut offrir une solution plus générale.
Une autre limite du HSTS est son inefficacité contre certains types d'attaques. Il ne protège pas, par exemple, contre les attaques par typosquattage, les attaques basées sur le DNS ou les attaques de l'homme du milieu utilisant de faux domaines qui ne sont pas inclus dans la liste de prélecture HSTS du navigateur.
Enfin, HSTS dépendant du protocole TLS, sa sécurité est liée à la robustesse de TLS. S'il existe des vulnérabilités dans TLS, HSTS sera indirectement affecté.
Pour une discussion plus détaillée et technique de ces aspects et d'autres aspects du HSTS, veuillez consulter la demande de commentaires (RFC) 6797.
Précharges HSTS
Le "préchargement" HSTS est une méthode utilisée pour améliorer la sécurité du site Web et surmonter l'une des principales limites du HSTS - le fait que l'utilisateur doit avoir déjà visité le site avant que la politique HSTS ne soit respectée. Le préchargement HSTS résout ce problème en incluant le site Web dans une liste prédéfinie de sites utilisant HSTS, distribuée avec le navigateur. Ainsi, lorsqu'un utilisateur visite le site pour la première fois, le navigateur sait déjà qu'il doit utiliser HTTPS, évitant ainsi le problème du « premier contact ».
hstspreload.org est un service qui permet aux propriétaires de sites Web de demander l'inclusion de leur site dans la liste de préchargement HSTS distribuée avec les principaux navigateurs. Pour être inclus dans cette liste, un site Web doit répondre à un certain nombre de critères spécifiés, y compris l'envoi d'un en-tête HSTS approprié avec une valeur "max-age" d'au moins 31536000 secondes (environ un an), et l'inclusion des "includeSubDomains" et directive "préchargement".
Pour configurer un serveur Web NGINX afin qu'il envoie les en-têtes corrects et réponde à ces critères, vous devez ajouter la configuration suivante dans le bloc « serveur » de votre fichier de configuration NGINX :
server { # ... autres configurations de serveur ... add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; # ... autres configurations de serveur ... } Une fois cette configuration implémentée, il est possible de demander l'inclusion du site (dans notre exemple, example.it) dans la liste de préchargement HSTS via hstspreload.org. Entrez simplement le domaine de votre site dans le champ de saisie fourni et suivez les instructions fournies. Le site sera ensuite vérifié pour s'assurer qu'il répond à tous les critères nécessaires, et si tout va bien, il sera ajouté à la liste.
Le processus de préchargement HSTS ne se produit pas en temps réel, mais plutôt en conjonction avec chaque nouvelle version de Google Chrome. En effet, la liste par défaut des sites utilisant HSTS est incluse dans chaque version du navigateur Google Chrome. Une fois qu'un site Web a demandé et satisfait aux exigences d'inclusion via hstspreload.org, le site est ajouté à la liste et ce changement est inclus dans la prochaine version de Google Chrome.
Cependant, il est important de noter qu'il peut y avoir une période d'attente importante avant que l'inclusion ne prenne effet. Google publie de nouvelles versions de Chrome toutes les six semaines environ, mais il peut y avoir un délai supplémentaire avant que la modification ne soit intégrée au navigateur. En effet, il peut y avoir de nombreuses demandes d'inclusion en attente et le processus d'examen et d'ajout à la liste prend du temps.
Dans l'ensemble, il faut s'attendre à ce qu'il faille au moins deux à trois mois pour qu'un site soit inclus dans la liste par défaut de Chrome après la demande initiale. Cependant, une fois inclus dans la liste, tous les visiteurs du site Web utilisant une version mise à jour de Chrome bénéficieront de la politique HSTS dès leur premier contact avec le site.
Préchargement HSTS et amélioration des performances et des valeurs TTFB.
Le préchargement HSTS (HTTP Strict Transport Security) améliore non seulement la sécurité globale du site Web, mais peut également contribuer à améliorer les performances globales du site et à réduire le délai avant le premier octet (TTFB). TTFB est une métrique qui mesure le temps qui s'écoule entre le moment où un client (par exemple, un navigateur Web) envoie une requête HTTP jusqu'à ce qu'il reçoive le premier octet de la réponse du serveur Web. La réduction du TTFB peut grandement améliorer la vitesse globale de chargement d'une page Web et l'expérience utilisateur.
Avec HSTS activé et configuré pour le préchargement, le navigateur de l'utilisateur sait à l'avance qu'il ne doit communiquer avec le site Web que via une connexion HTTPS sécurisée, éliminant ainsi le besoin d'une redirection HTTP vers HTTPS. Cette redirection peut introduire des latences supplémentaires qui augmentent le TTFB.
Sans HSTS, le navigateur de l'utilisateur peut initialement tenter d'établir une connexion HTTP non sécurisée, que le serveur redirige ensuite vers une connexion HTTPS. Cette redirection prend du temps et ralentit le chargement de la page.
Avec le préchargement HSTS, cette redirection est évitée, ce qui peut entraîner une réduction du TTFB, rendant le site Web plus rapide et plus réactif. Il s'agit d'un avantage particulièrement important pour les sites Web hautes performances, où même des améliorations mineures du TTFB peuvent avoir un impact considérable sur l'expérience utilisateur et la vitesse globale du site.
Quelles sont les meilleures pratiques pour déployer le HSTS ?
Les meilleures pratiques de déploiement HTTP Strict Transport Security (HSTS) sont conçues pour optimiser la sécurité de votre site et garantir que tous les visiteurs de votre site bénéficient de la protection offerte par HSTS. Ici, nous allons nous concentrer sur la façon de déployer avec succès HSTS si votre site est lié à HTTPS et que vous avez l'intention de précharger HSTS. Les étapes suivantes décrivent le processus :
- Assurez-vous de fournir un certificat valide : Un certificat SSL/TLS valide est essentiel pour établir une connexion HTTPS sécurisée. Cela implique que le certificat doit être délivré par une autorité de certification (CA) reconnue et que le nom de votre site doit correspondre au nom spécifié dans le certificat.
- Rediriger de HTTP vers HTTPS sur le même hôte, si vous écoutez sur le port 80 : cette étape est essentielle pour garantir la sécurité de toutes les connexions à votre site. Toutes les requêtes HTTP doivent être redirigées vers HTTPS sur le même hôte.
- Servir tous les sous-domaines via HTTPS : Assurez-vous que tous les sous-domaines de votre site utilisent HTTPS pour garantir des connexions sécurisées sur l'ensemble de votre domaine.
- Prend en charge HTTPS pour le sous-domaine www si un enregistrement DNS existe pour ce sous-domaine : si votre site possède un enregistrement DNS pour un sous-domaine www, il doit prendre en charge HTTPS.
- Nécessite un en-tête HSTS dans le domaine de base pour les requêtes HTTPS : l'en-tête doit spécifier un âge maximal d'au moins 31536000 secondes (1 an), doit inclure la directive includeSubDomains et la directive preload.
- Si vous diffusez une redirection supplémentaire à partir de votre site HTTPS, cette redirection doit toujours avoir l'en-tête HSTS.
Pour atteindre un niveau de sécurité optimal, il est recommandé de suivre ces étapes :
- Commencez par examiner tous les sous-domaines et sous-domaines imbriqués de votre site pour vous assurer qu'ils fonctionnent sur HTTPS.
- Ensuite, activez HSTS pour toutes les réponses HTTPS et augmentez progressivement l'âge maximum. Au cours de chaque étape, surveillez de près les métriques de votre site, résolvez les problèmes qui surviennent et attendez l'âge maximum de l'étape avant de continuer. Vous pouvez suivre cette progression pour l'âge maximum de l'en-tête : 5 minutes, 1 semaine, 1 mois.
- Une fois que vous êtes sûr qu'il n'y a pas de problème, augmentez l'âge maximum à 2 ans et soumettez votre site à la liste de prélecture HSTS avec la directive de prélecture.
Enfin, vous pouvez soumettre votre site Web pour inclusion dans la liste de préchargement HSTS via hstspreload.org. Ce site est géré par l'équipe du projet Chromium et permet aux sites Web d'être inclus dans la liste de préchargement HSTS distribuée avec Chrome et d'autres navigateurs basés sur Chromium.
Quels navigateurs prennent en charge HSTS ?
HSTS (HTTP Strict Transport Security) bénéficie d'un large soutien parmi les principaux navigateurs, confirmant son rôle vital dans l'augmentation de la sécurité des connexions Internet.
Chromium et Google Chrome ont été parmi les premiers navigateurs à prendre en charge HSTS, à partir de la version 4.0.211.0. Cela a marqué une avancée majeure dans la mise en œuvre de mesures de sécurité avancées pour protéger les internautes contre les attaques potentielles.
Firefox a commencé à prendre en charge HSTS à partir de la version 4. Mais avec l'introduction de Firefox 17, Mozilla est allé encore plus loin en intégrant une liste de sites Web prenant en charge HSTS, améliorant encore la sécurité des utilisateurs.
Opera, à partir de la version 12, a commencé à prendre en charge HSTS, reconnaissant l'importance de fournir une connexion sécurisée à ses utilisateurs.
Safari a commencé à prendre en charge HSTS à partir d'OS X Mavericks, version 10.9. Cela a fourni une couche de protection supplémentaire aux utilisateurs de Safari, les aidant à naviguer sur Internet de manière plus sécurisée.
Internet Explorer 11 sur Windows 8.1 et Windows 7 a commencé à prendre en charge HSTS lors de l'installation de la mise à jour KB 3058515. Cela a permis à ses utilisateurs de bénéficier des protections offertes par HSTS.
Microsoft Edge et Internet Explorer 11 sur Windows 10 prennent en charge HSTS, renforçant encore la sécurité de ces navigateurs.
Enfin, le navigateur BlackBerry 10 et WebView prennent également en charge HSTS, à partir de BlackBerry OS 10.3.3. Cela confirme l'importance du HSTS non seulement pour les ordinateurs de bureau, mais également pour les appareils mobiles.
Conclusions
En bref, HTTP Strict Transport Security (HSTS) est un mécanisme de sécurité important qui aide à protéger les sites Web et leurs utilisateurs contre divers types d'attaques, y compris les attaques de type "man-in-the-middle". Cela fonctionne en forçant les navigateurs à utiliser des connexions HTTPS sécurisées avec des sites Web qui mettent en œuvre la politique HSTS.
Cependant, HSTS a certaines limites. Il oblige l'utilisateur à visiter d'abord le site Web pour connaître sa politique HSTS, ce qui peut exposer la première demande à des attaques potentielles. C'est là que le préchargement HSTS entre en jeu. Le préchargement HSTS permet aux sites Web d'être inclus dans une liste de sites HSTS qui est distribuée avec les navigateurs, éliminant ainsi la nécessité pour l'utilisateur de visiter d'abord le site pour connaître sa politique HSTS.
La configuration du préchargement HSTS nécessite quelques étapes, notamment la définition d'en-têtes spécifiques et la soumission de votre site à la liste de préchargement HSTS. Bien qu'il puisse être un peu complexe à mettre en place, il offre une couche de sécurité supplémentaire qui mérite d'être prise en compte.
En outre, le préchargement HSTS peut également améliorer les performances du site Web en réduisant le délai avant le premier octet (TTFB), ce qui peut conduire à une meilleure expérience utilisateur.
Enfin, HSTS offre une large compatibilité avec les navigateurs, notamment Google Chrome, Mozilla Firefox, Internet Explorer, Microsoft Edge, Opera, Safari et le navigateur BlackBerry 10.
