Contenu mixte derrière un VPN : réparer la ressource, pas le tunnel

Une page HTTPS qui charge des scripts en HTTP fait deux requêtes avec deux niveaux de protection différents, et le cadenas ne décrit que la première. Un tunnel n’y change rien, car il protège le transport et non le schéma propre de la ressource. Le navigateur vous dit déjà quelle requête a échoué, si vous lisez la console plutôt que la barre d’adresse. Trois vérifications vous mènent d’une page à moitié fonctionnelle à une véritable réparation.

Lisez la requête, pas la barre d’adresse

Un document récupéré en HTTPS peut référencer un script, une feuille de style, une police ou un cadre en HTTP simple. Cette référence est une requête distincte, et c’est elle dont le navigateur se plaint. La protection du document principal ne remonte pas jusqu’à elle, et le tunnel qui transporte les deux flux n’altère aucun des deux schémas. La page peut donc être à la fois réellement sécurisée et réellement cassée.

Qualifier la ressource de simple fichier inclus ne rend pas son remplacement inoffensif.

Si un contenu de script non sécurisé peut être modifié en transit puis exécuté, il peut changer le comportement de la page, ce qui est un problème plus grave qu’une défaillance cosmétique. Les images présentent un risque plus faible mais réel lorsqu’elles sont modifiées en chemin. Le cadenas ne ment sur rien. Il répond à une question plus étroite que celle que vous lui avez posée.

Sachez quelles ressources sont bloquées et lesquelles sont promues

Les navigateurs ne traitent pas tous les types de ressources de la même manière. les recommandations sur le contenu mixte séparent les requêtes promues en HTTPS de celles qui sont bloquées d’office, les scripts, les feuilles de style et les requêtes programmatiques étant du côté bloqué, tandis que les images et les médias peuvent au contraire être promus ou signalés.

Cette différence explique les rapports déroutants. Une page dont un script est bloqué perd entièrement une fonctionnalité, tandis qu’une page dont une image est promue semble correcte et a discrètement changé sa requête. Les catégories documentées comportent aussi des exceptions, alors ne supposez pas que toute URL d’un type donné sera promue avec succès. Lisez ce que la console dit de la requête précise plutôt que de raisonner à partir d’une extension de fichier.

Un widget bloqué n’est pas la preuve que le tunnel a échoué. C’est la preuve que le navigateur a fait son travail.

Réparez la référence à sa source

Pour le propriétaire d’un site, la réparation se situe là où l’URL non sécurisée a été écrite : un modèle, une feuille de style, un script qui assemble des URL ou un composant tiers. Changer l’adresse visible de la page laisse tout cela intact. Cherchez l’hôte dans la source et réparez chaque référence, pas seulement celle que la console a citée par hasard.

Confirmez ensuite que la ressource est réellement servie en HTTPS avec une identité valide, car un changement de schéma ne peut pas faire apparaître un service qui n’y a jamais été publié.

grep -rn "http://assets.example" ./templates
curl -sSI https://assets.example/widget.js | head -n 1

Suivez aussi les redirections, car une référence qui commence en HTTPS peut tout de même aboutir sur un chemin de livraison en texte clair. Lorsqu’une dépendance n’a tout simplement pas de livraison sécurisée disponible, retirez-la ou remplacez-la via le processus de changement habituel plutôt que de livrer un contournement. Pour un utilisateur, laissez les protections du navigateur activées et signalez au propriétaire du site l’URL de la ressource, son type et le message de la console. Ne diffusez jamais d’instructions demandant au personnel d’autoriser du contenu non sécurisé pour une page, car cette exception survit à l’incident qui l’a motivée.

Retestez la page telle que les utilisateurs la touchent

Exercez les opérations qui chargent des ressources à la demande, pas seulement le premier document. Les pages récupèrent du code, des données et des téléchargements supplémentaires après un appui sur un bouton, et ces requêtes sont souvent les non sécurisées. Confirmez les requêtes précises et le comportement visible avec la protection toujours active. Un test qui commence avec un profil de navigateur assoupli ne peut pas vous montrer ce que voit un utilisateur normal.

Le tunnel a toujours son propre travail, et ce travail est l’accès au réseau, non l’intégrité de la page.

Une fois que le trafic quitte le point de sortie du tunnel, toute requête HTTP restante n’a rien gagné du transport. Réparez le chemin de la ressource et maintenez l’application dans le navigateur. Traiter une couche de transport supplémentaire comme la réparation d’une dépendance non sécurisée, c’est ainsi qu’une équipe finit avec un script de support qui désactive le contrôle qui fonctionnait correctement.