Skip to main content

10 raisons d’utiliser HTTPS

Écrit par

10 juillet 2015

0 minutes de lecture

HTTPS, c’est HTTP sur TLS. Depuis son apparition en 1994, il est largement adopté par les sites pour lesquels la sécurité est essentielle : banques en ligne, sites marchands, services fiscaux et bien d’autres. Pourtant, l’immense majorité des sites web (entre 81 % et 97 % selon les estimations) communiquent encore en HTTP en clair (sans chiffrement), malgré les risques que cela comporte.

Graphique linéaire intitulé « Statistiques d’utilisation du SSL par défaut », montrant la progression de l’utilisation du SSL parmi les 10 000, 100 000 et 1 million de sites Web les plus populaires.

Statistiques de BuiltWith montrant une adoption encore faible, mais en hausse, de HTTPS

Aujourd’hui, il existe pourtant plus de raisons que jamais de passer à HTTPS, même pour un site d’actualités, un site d’entreprise ou tout site qui ne se considère pas comme une cible de choix pour les cyberattaques. L’adoption de HTTPS a progressé de 80 % l’an dernier, bien plus rapidement que les années précédentes, mais nous sommes encore très loin du chiffrement généralisé. Si vous n’êtes pas convaincu que HTTPS est fait pour vous, ou si vous avez besoin d’arguments pour convaincre vos collègues et votre direction, voici 10 bonnes raisons de passer à HTTPS.

1. Protégez la vie privée de vos utilisateurs

Avant tout, HTTPS protège vos utilisateurs. Publier une actualité sur un forum peut coûter la vie à un dissident sous un régime oppressif ; un employeur strict peut licencier un salarié en fonction de son activité de navigation ; et, bien sûr, les affaires Snowden ont clairement montré que les gouvernements ne se lassent pas de collecter ces données. HTTPS complique considérablement la tâche de ceux qui cherchent à savoir ce que font les utilisateurs et vous aide à honorer votre responsabilité la plus importante : la confiance de vos utilisateurs.

2. Référencement dans les moteurs de recherche (SEO)

L’an dernier (2014), Google a annoncé que HTTPS serait pris en compte dans le classement des résultats. Comme les autres moteurs de recherche, Google cherche à mettre en avant les liens les plus utiles aux internautes. Un site qui protège leur vie privée avec HTTPS leur est donc plus favorable qu’un site qui ne le fait pas. Que vous y voyiez une carotte (utilisez HTTPS et vous serez récompensé) ou un bâton (utilisez HTTPS, sinon votre classement sera pénalisé), peu de choses mobilisent les entreprises autant que le SEO. Pour savoir plus précisément comment optimiser HTTPS à des fins de SEO, consultez cet article de Moz.

3. Protégez votre image de marque

Le contenu non chiffré peut facilement être modifié. Un utilisateur qui consulte un site d’actualités sur un réseau Wi-Fi malveillant peut lire des faits rapportés qui ne se sont jamais produits. Un site d’entreprise peut afficher de fausses excuses attribuées à un PDG accusé de détournement de fonds. Et n’importe quel site non sécurisé peut être modifié pour afficher du contenu pornographique (ou pire). De plus, les pages non chiffrées se trouvent souvent sur le chemin qui mène aux pages sécurisées. Prenons l’exemple d’un site marchand dont la page produit n’est pas chiffrée, mais dont le parcours d’achat utilise HTTPS. Un attaquant de type « homme du milieu » peut modifier la page produit non protégée et rediriger le bouton « Ajouter au panier » vers sa copie malveillante du site. Le navigateur (et l’utilisateur) n’y verra que du feu. Si vous voulez que vos utilisateurs voient uniquement le contenu que vous avez réellement publié et que leurs actions vous parviennent toujours, utilisez HTTPS.

4. Les navigateurs signaleront HTTP comme non sécurisé

Aujourd’hui, les navigateurs indiquent qu’une connexion HTTPS est utilisée en affichant l’URL en vert ou un cadenas, uniquement si le site est correctement chiffré. Ces indicateurs donnent en réalité un faux sentiment de sécurité : ils laissent entendre que les sites HTTPS sont sécurisés, alors qu’ils peuvent être très vulnérables une fois que vous avez atteint le serveur. Ce qui est exact, c’est que les connexions HTTP non chiffrées sont non sécurisées. Les navigateurs s’apprêtent désormais à adapter leurs indicateurs en conséquence. Google et Firefox ont tous deux annoncé qu’ils allaient d’abord signaler les sites HTTP comme suspects, puis comme non sécurisés, peut-être dès cette année. Si vous restez sur HTTP, vos utilisateurs pourraient être explicitement avertis que votre site n’est pas sécurisé, ce qui réduirait leur confiance. Remarque : l’efficacité des indicateurs passifs, positifs comme négatifs, est minime, et les navigateurs pourraient faire évoluer ces avertissements vers des alertes nécessitant une confirmation de l’utilisateur.

5. HTTP/2

Environ 18 ans après sa création, HTTP/1.1 va enfin être modernisé. Son successeur, HTTP/2, a été officiellement finalisé en mai 2015. HTTP/2 fait évoluer le protocole SPDY de Google et apporte de nombreuses améliorations majeures par rapport à HTTP/1.1, du multiplexage des requêtes à la compression des en-têtes, en passant par le push côté serveur. Pour des raisons de compatibilité et parce qu’ils souhaitent rendre le Web plus sûr, les navigateurs ne prendront en charge HTTP/2 que sur HTTPS (la spécification précise que le chiffrement est facultatif). Pour profiter de cette évolution du Web, vous devez passer à HTTPS.

6. Service Worker et fonctionnalités avancées

Autre avancée passionnante des navigateurs, dont l’impact est comparable à celui de HTTP/2, même si elle est moins connue : ServiceWorker. Sa principale force est de permettre aux applications web de fonctionner comme des applications natives, notamment hors ligne et avec des notifications push. Il remplace avantageusement AppCache et repose sur les principes de l’Extensible Web Manifesto. Techniquement, ServiceWorker agit comme un proxy JavaScript, installé de façon transparente lors de la visite d’un site. Ce proxy est extrêmement puissant et peut étendre les fonctionnalités d’une page bien au-delà de la prise en charge du mode hors ligne. L’installation d’un ServiceWorker malveillant peut causer des dommages considérables et persistants, bien plus graves qu’une simple modification du trafic HTTP. Pour limiter ce risque, ServiceWorker et toutes ses nouvelles fonctionnalités ne sont disponibles que sur HTTPS. Les navigateurs favorisent un Web sécurisé, et vous pouvez vous attendre à ce que d’autres fonctionnalités avancées, comme la géolocalisation et le plein écran, ne fonctionnent que sur HTTPS.

The ServiceWorker: The network layer is yours to own

Vidéo de présentation de ServiceWorker, par Jake Archibald

7. Protégez vos revenus (des proxys)

Les criminels ne sont pas les seuls à vouloir tirer profit de votre site : les fournisseurs d’accès à Internet et de Wi-Fi aussi. Jusqu’à 38 % des proxys Wi-Fi, des géants comme Comcast aux plus petits fournisseurs, injectent leurs propres publicités dans les pages non chiffrées. Si la publicité est votre source de revenus, sachez que ces annonces peuvent être détournées sans que vos utilisateurs s’en rendent compte. Et si votre site n’affiche pas de publicités… vos utilisateurs pourraient quand même en voir, et vous en tenir responsable. Utilisez HTTPS pour empêcher ces modifications et protéger vos revenus et votre image de marque.

Capture d’écran du site web de l’Apple Store présentant une promotion sur l’iMac et les catégories Mac, iPad, iPhone et iPod

Une publicité H&R Block sur la page de l’Apple Store, injectée par CMA en 2013 » (Et pourtant, la page d’accueil de l’Apple Store n’utilise toujours pas HTTPS.)

8. Des données analytiques plus précises : les référents HTTPS

HTTPS vise à protéger votre vie privée, notamment en empêchant le partage de votre historique de navigation. Imaginez que vous visitiez https://secret.com/HelloKitty/, puis cliquiez sur un lien vers le site non chiffré http://other.com/. Si la requête vers other.com incluait l’URL dans un en-tête Referer (sic), quiconque pourrait l’intercepter (ainsi que other.com) saurait que vous aimez cette petite créature qui n’est pas un chat. Pour éviter cette atteinte à la vie privée, les navigateurs n’envoient pas d’en-tête Referer lorsque l’on passe de HTTPS à HTTP (sauf si ce comportement est explicitement modifié à l’aide d’une politique de référent). À mesure que les sites passent à HTTPS, rester sur HTTP vous donnera moins d’informations sur l’origine de vos visiteurs.

9. Compatibilité avec les API d’iOS 9+ et d’Android 5+

L’adoption de TLS ne se limite pas aux navigateurs. Lors de sa dernière conférence destinée aux développeurs, Apple a annoncé qu’iOS 9 imposerait l’utilisation de TLS pour toutes les connexions. Voici un extrait de la documentation d’iOS 9 :

Si vous développez une nouvelle application, utilisez exclusivement HTTPS. Si vous avez déjà une application, utilisez HTTPS autant que possible dès maintenant et prévoyez de migrer le reste de l’application dès que possible. De plus, vos communications via des API de plus haut niveau doivent être chiffrées avec TLS 1.2 et le secret de transmission. Toute tentative de connexion qui ne respecte pas cette exigence génère une erreur.

Android M devrait imposer une exigence similaire, quoique légèrement moins stricte, ce qui laisse entendre que ce sera le comportement par défaut des applications natives. Ce changement de paramètres par défaut concerne non seulement les développeurs d’applications natives, mais aussi toutes les personnes qui créent du contenu susceptible d’être consulté par des applications natives iOS. Si vous ne prenez pas en charge HTTPS, les développeurs iOS auront d’autant plus de mal à adopter votre API.

10. Intégration par des tiers

Pour préserver la sécurité du contenu d’une page, une page HTTPS ne peut pas charger de ressource HTTP non sécurisée. Cela entraîne généralement un avertissement de contenu mixte, à quelques rares exceptions près, comme les iframes sandboxées. Les sites qui tentent de passer à HTTPS découvrent souvent que de nombreux composants tiers qu’ils utilisent ne prennent pas HTTPS en charge. Ils doivent alors soit rester sur HTTP, soit supprimer le composant tiers concerné. Historiquement, la plupart des sites ont choisi de rester sur HTTP, mais la tendance pourrait s’inverser à mesure que les raisons de sécuriser le Web se multiplient. Si vous produisez du contenu susceptible d’être intégré à d’autres sites, ajoutez rapidement la prise en charge de HTTPS. Vous pourriez ainsi bénéficier d’un avantage concurrentiel dès aujourd’hui et, bientôt, HTTPS sera indispensable à votre survie.

Lancez votre projet HTTPS dès aujourd’hui !

Cet article présente plusieurs raisons de passer à HTTPS, mais pas les difficultés que cela implique. Des tiers non sécurisés, les coûts ou d’autres contraintes héritées (mais pas les performances !) peuvent rendre la transition difficile. Il reste toutefois essentiel de comprendre que HTTPS n’est pas près de disparaître. Plus vous tardez à commencer la migration, plus vous vous enfoncez. De nouvelles initiatives proposent gratuitement et simplement des certificats, des services CDN, des outils de test et bien plus encore pour vous aider à surmonter certains obstacles. Alors, lancez-vous dès maintenant : établissez un plan, faites-le approuver et commencez à sécuriser votre site.

Lire la suite

feature insights context
Blog

Les attaques autonomes sont déjà là. La défense doit suivre leur rythme.

Les attaquants autonomes réduisent la fenêtre de défense. Découvrez comment la découverte, la correction, la validation et la prévention continues peuvent aider les équipes de sécurité à suivre le rythme.

illustration hero ai
Blog

Qu’est-ce que l’AppSec agentique ?

Découvrez comment l’AppSec agentique s’appuie sur des agents IA ancrés dans la réalité, aux missions délimitées et vérifiés de manière indépendante pour gérer le cycle de sécurité des applications.

Blog

Evo ADS : la gouvernance des comportements des agents est disponible : maîtrisez l’utilisation de MCP

La gouvernance des comportements des agents Evo ADS est désormais disponible, avec MCP Governance en première étape. Découvrez, approuvez, surveillez, consignez et bloquez l’utilisation des serveurs MCP par les principaux agents de programmation IA.