Corriger le contenu mixte

Jo-el van Bergen
Jo-el van Bergen
X
Rachel Andrew

La prise en charge du protocole HTTPS pour votre site Web est une étape importante pour protéger votre site et vos utilisateurs contre les attaques, mais le contenu mixte peut rendre cette protection inutile. Les navigateurs bloqueront de plus en plus les contenus mixtes non sécurisés, comme expliqué dans Qu'est-ce qu'un contenu mixte ?

Dans ce guide, nous allons vous présenter des techniques et des outils permettant de résoudre les problèmes de contenu mixte existants et d'éviter qu'ils ne se reproduisent.

Rechercher du contenu mixte en visitant votre site

Lorsque vous consultez une page HTTPS dans Google Chrome, le navigateur vous signale les contenus mixtes sous forme d'erreurs et d'avertissements dans la console JavaScript.

Dans Qu'est-ce que le contenu mixte ?, vous trouverez un certain nombre d'exemples et verrez comment les problèmes sont signalés dans les outils pour les développeurs Chrome.

Voici un exemple d'avertissements pour un contenu mixte passif. Si le navigateur parvient à trouver le contenu à une URL https, il le met automatiquement à niveau, puis affiche un message.

Outils pour les développeurs Chrome affichant les avertissements qui s'affichent lorsque du contenu mixte est détecté et mis à niveau

Le contenu mixte actif est bloqué et un avertissement s'affiche.

Outils pour les développeurs Chrome affichant les avertissements qui s'affichent lorsque du contenu mixte actif est bloqué

Si vous trouvez 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 dresser une liste de ces URL, ainsi que de la page sur laquelle vous les avez trouvées, afin de pouvoir les corriger.

Rechercher du contenu mixte sur votre site

Vous pouvez rechercher du contenu mixte directement dans votre code source. Recherchez http:// dans votre source et recherchez 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>) n'est souvent pas un problème de contenu mixte, à quelques exceptions notables près, que nous aborderons plus tard.

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 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 remplacer l'URL http:// de la ressource par https:// dans votre code en toute sécurité. 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'URL du navigateur et en essayant d'ouvrir l'URL dans un onglet du navigateur.

Si la ressource n'est pas disponible via https://, vous devez envisager l'une des options suivantes :

  • Incluez la ressource d'un autre hôte, si disponible.
  • Téléchargez et hébergez le contenu directement sur votre site, si vous y êtes légalement autorisé.
  • Excluez complètement la ressource de votre site.

Une fois le problème résolu, affichez la page où vous avez trouvé l'erreur à l'origine et vérifiez qu'elle n'apparaît plus.

Attention à l'utilisation de balises non standards

Méfiez-vous de 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. Cependant, 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 un affichage lightbox sur la page, ce qui entraîne 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. Toutefois, pour les sites Web volumineux ou les sites comptant de nombreuses équipes de développement distinctes, il peut être difficile de suivre l'ensemble du contenu chargé. Pour vous aider dans cette tâche, vous pouvez utiliser une Content Security Policy (CSP) afin d'indiquer au navigateur de vous informer de la présence de 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 signalement 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.

Rechercher du contenu mixte avec une Content Security Policy

Vous pouvez utiliser la Content Security Policy pour collecter des rapports sur le contenu mixte 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 consulte une page de votre site, son navigateur envoie des rapports au format JSON concernant tout ce qui ne respecte pas la Content Security Policy à https://example.com/reportingEndpoint. Dans ce cas, chaque fois qu'une sous-ressource est chargée via HTTP, un rapport est envoyé. Ces rapports incluent l'URL de la page où le non-respect des règles s'est produit et l'URL de la sous-ressource qui a enfreint les règles. Si vous configurez votre point de terminaison de reporting pour consigner ces rapports, vous pouvez suivre le contenu mixte sur votre site sans avoir à consulter chaque page vous-même.

Il existe deux exceptions :

  • 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 des rapports que pour les pages consultées par vos utilisateurs. Par conséquent, si certaines pages de votre site ne génèrent pas beaucoup de trafic, il peut s'écouler un certain temps avant que vous ne receviez des rapports pour l'ensemble de votre site.

Le guide Content Security Policy contient plus d'informations et un exemple de point de terminaison.

Alternatives aux rapports avec CSP

Si votre site est hébergé par une plate-forme telle que Blogger, vous n'avez peut-être pas accès à la modification des en-têtes ni à l'ajout d'une CSP. Une alternative viable consiste à utiliser un robot d'exploration de site Web pour détecter les problèmes sur votre site, comme HTTPSChecker ou Mixed Content Scan.

Mise à niveau des requêtes non sécurisées

Browser Support

  • Chrome: 44.
  • Edge: 17.
  • Firefox: 48.
  • Safari: 10.1.

Source

Les navigateurs commencent à mettre à niveau et à bloquer les requêtes non sécurisées. Vous pouvez utiliser des directives CSP pour forcer la mise à niveau automatique ou le blocage de ces éléments.

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 une balise d'image avec une URL HTTP telle que <img src="https://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

Vous pouvez également intégrer 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 via 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.

La directive upgrade-insecure-requests s'applique en cascade aux documents <iframe>, ce qui garantit la protection de l'intégralité de la page.

Précédent
Qu'est-ce que le contenu mixte ?
Suivant
Quand utiliser HTTPS pour le développement local ?