L'utilisation du protocole HTTPS pour votre site Web est une étape importante pour protéger votre site et vos utilisateurs contre les attaques. Toutefois, le contenu mixte peut rendre cette protection inutile. Les navigateurs bloqueront de plus en plus de contenu mixte non sécurisé, comme expliqué dans Qu'est-ce que le contenu mixte ?
Dans ce guide, nous allons vous montrer des techniques et des outils pour résoudre les problèmes de contenu mixte existants et éviter qu'ils ne se reproduisent.
Identifier les contenus mixtes en visitant votre site
Lorsque vous consultez une page HTTPS dans Google Chrome, le navigateur vous alerte sur le contenu mixte sous forme d'erreurs et d'avertissements dans la console JavaScript.
Dans Qu'est-ce que le contenu mixte ?, vous trouverez plusieurs exemples et découvrirez comment les problèmes sont signalés dans les outils pour les développeurs Chrome.
L'exemple de contenu mixte passif générera les avertissements suivants.
Si le navigateur parvient à trouver le contenu à une URL https, il le met automatiquement à niveau, puis affiche un message.
Le contenu mixte actif est bloqué et un avertissement s'affiche.
Si vous voyez des avertissements de ce type pour des URL http:// sur votre site, vous devez les corriger dans la source de votre site.
Il est utile de créer une liste de ces URL, ainsi que de la page sur laquelle vous les avez trouvées, pour les corriger.
Identifier le contenu mixte sur votre site
Vous pouvez rechercher du contenu mixte directement dans votre code source.
Recherchez http:// dans votre source et identifiez les balises qui incluent des attributs d'URL HTTP.
Notez que la présence de http:// dans l'attribut href des balises d'ancrage (<a>) ne constitue généralement pas un problème de contenu mixte, à quelques exceptions notables près qui seront abordées plus loin.
Si votre site est publié à l'aide d'un système de gestion de contenu, il est possible que des liens vers des URL non sécurisées soient insérés lors de la publication des pages. Par exemple, les images peuvent être incluses avec une URL complète plutôt qu'un chemin d'accès relatif. Vous devrez les trouver et les corriger dans le contenu du CMS.
Corriger le contenu mixte
Une fois que vous avez trouvé du contenu mixte dans la source de votre site, vous pouvez suivre ces étapes pour le corriger.
Si un message de la console indique qu'une requête de ressource a été automatiquement mise à niveau de HTTP vers HTTPS, vous pouvez modifier l'URL http:// de la ressource dans votre code en https:// sans risque.
Vous pouvez également vérifier si une ressource est disponible de manière sécurisée en remplaçant http:// par https:// dans la barre d'adresse du navigateur et en essayant d'ouvrir l'URL dans un onglet du navigateur.
Si la ressource n'est pas disponible via https://, vous pouvez envisager l'une des options suivantes :
- Incluez la ressource à partir d'un autre hôte, si disponible.
- Téléchargez et hébergez le contenu directement sur votre site, si vous êtes légalement autorisé à le faire.
- Excluez complètement la ressource de votre site.
Après avoir résolu le problème, consultez la page sur laquelle vous avez initialement trouvé l'erreur et vérifiez qu'elle n'apparaît plus.
Attention à l'utilisation non standard des balises
Faites attention à l'utilisation de balises non standards sur votre site.
Par exemple, les URL de balise d'ancrage (<a>) ne génèrent pas d'erreurs de contenu mixte, car elles entraînent la navigation du navigateur vers une nouvelle page.
Cela signifie qu'ils n'ont généralement pas besoin d'être corrigés.
Toutefois, certains scripts de galerie d'images remplacent la fonctionnalité de la balise <a> et chargent la ressource HTTP spécifiée par l'attribut href dans une lightbox sur la page, ce qui pose un problème de contenu mixte.
Gérer le contenu mixte à grande échelle
Les étapes manuelles ci-dessus fonctionnent bien pour les petits sites Web, mais pour les grands sites ou ceux qui comptent de nombreuses équipes de développement distinctes, il peut être difficile de suivre tout le contenu chargé. Pour vous aider dans cette tâche, vous pouvez utiliser une Content Security Policy afin d'indiquer au navigateur de vous avertir du contenu mixte et de vous assurer que vos pages ne chargent jamais de ressources non sécurisées de manière inattendue.
Content Security Policy
La Content Security Policy (CSP) est une fonctionnalité de navigateur polyvalente que vous pouvez utiliser pour gérer le contenu mixte à grande échelle. Le mécanisme de création de rapports CSP peut être utilisé pour suivre le contenu mixte sur votre site et fournir des règles d'application pour protéger les utilisateurs en mettant à niveau ou en bloquant le contenu mixte.
Vous pouvez activer ces fonctionnalités pour une page en incluant l'en-tête Content-Security-Policy ou Content-Security-Policy-Report-Only dans la réponse envoyée par votre serveur.
Vous pouvez également définir Content-Security-Policy (mais pas Content-Security-Policy-Report-Only) à l'aide d'une balise <meta> dans la section <head> de votre page.
Identifier le contenu mixte avec la règle de sécurité du contenu
Vous pouvez utiliser la stratégie Content Security Policy pour collecter des rapports sur les contenus mixtes de votre site.
Pour activer cette fonctionnalité, définissez la directive Content-Security-Policy-Report-Only en l'ajoutant en tant qu'en-tête de réponse pour votre site.
En-tête de réponse :
Content-Security-Policy-Report-Only: default-src https: 'unsafe-inline' 'unsafe-eval'; report-uri https://example.com/reportingEndpoint
Chaque fois qu'un utilisateur visite une page de votre site, son navigateur envoie des rapports au format JSON concernant tout ce qui enfreint la règle de sécurité du contenu à https://example.com/reportingEndpoint.
Dans ce cas, un rapport est envoyé chaque fois qu'une sous-ressource est chargée via HTTP.
Ces rapports incluent l'URL de la page où le non-respect des règles a eu lieu et l'URL de la sous-ressource qui ne respecte pas les règles.
Si vous configurez votre point de terminaison de création de rapports pour consigner ces rapports, vous pouvez suivre le contenu mixte sur votre site sans avoir à visiter chaque page vous-même.
Veillez à tenir compte des deux points suivants :
- Les utilisateurs doivent accéder à votre page dans un navigateur qui comprend l'en-tête CSP. C'est le cas de la plupart des navigateurs récents.
- Vous ne recevez de rapports que pour les pages consultées par vos utilisateurs. Par conséquent, si certaines de vos pages ne génèrent pas beaucoup de trafic, il faudra peut-être attendre un certain temps avant de recevoir des rapports pour l'ensemble de votre site.
Le guide Stratégie de sécurité du contenu contient plus d'informations et un exemple de point de terminaison.
Alternatives au reporting avec CSP
Si votre site est hébergé pour vous par une plate-forme telle que Blogger, vous n'aurez peut-être pas accès à la modification des en-têtes ni à l'ajout d'une CSP. Une alternative viable pourrait être d'utiliser un robot d'exploration de site Web pour identifier les problèmes sur votre site, comme HTTPSChecker ou Mixed Content Scan.
Mise à niveau des requêtes non sécurisées
Les navigateurs commencent à mettre à niveau et à bloquer les requêtes non sécurisées. Vous pouvez utiliser les directives CSP pour forcer la mise à niveau automatique ou le blocage de ces ressources.
La directive CSP upgrade-insecure-requests indique au navigateur de mettre à niveau les URL non sécurisées avant d'effectuer des requêtes réseau.
Par exemple, si une page contient un tag d'image avec une URL HTTP telle que
<img src="http://example.com/image.jpg">
Le navigateur envoie plutôt une requête sécurisée pour https://example.com/image.jpg, ce qui évite à l'utilisateur de voir du contenu mixte.
Vous pouvez activer ce comportement en envoyant un en-tête Content-Security-Policy avec cette directive :
Content-Security-Policy: upgrade-insecure-requests
Ou en intégrant cette même directive dans la section <head> du document à l'aide d'un élément <meta> :
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Comme pour la mise à niveau automatique du navigateur, si la ressource n'est pas disponible sur HTTPS, la requête mise à niveau échoue et la ressource n'est pas chargée.
Cela permet de préserver la sécurité de votre page. La directive upgrade-insecure-requests va plus loin que la mise à niveau automatique du navigateur, en tentant de mettre à niveau les requêtes que le navigateur ne met pas à niveau actuellement.
L'instruction upgrade-insecure-requests se propage aux documents <iframe>, ce qui garantit la protection de l'ensemble de la page.