Le contenu mixte apparaît lorsqu’une page chargée de manière sécurisée utilise des ressources demandées par une connexion non sécurisée. Le vérificateur de contenu mixte de Screpy repère les références HTTP dans le HTML source d’une page HTTPS publique, puis affiche leur catégorie, leur adresse, leur première ligne et leur nombre d’occurrences. Ces informations permettent de retrouver le contenu ou le modèle à corriger et de préparer un remplacement sécurisé.
Le rapport n’exécute pas la page et ne récupère pas les ressources répertoriées. Il identifie les références à examiner, sans enregistrer ce que le navigateur d’un visiteur a réellement chargé, passé en HTTPS ou bloqué. Une vérification réussie ne certifie pas non plus la sécurité de tout le site.
Vérifier la page HTTPS qui contient les références
Saisissez l’adresse publique complète de la page à examiner. Pour un article, envoyez son URL, comme l’adresse illustrative https://example.com/guides/setup/, plutôt que la page d’accueil ou l’image soupçonnée d’être non sécurisée. L’outil analyse une page fournie ; il ne découvre pas toutes les pages du domaine.
La saisie exige HTTPS. Après la vérification, lisez l’URL finale : les redirections peuvent changer la page analysée. Si une adresse HTTPS aboutit à HTTP, l’analyse de contenu mixte HTTPS ne s’applique pas. Ce n’est pas un résultat sans problème. Utilisez le vérificateur de redirections pour examiner une destination inattendue.
La page doit renvoyer du HTML public lisible. Un écran de connexion peut contenir d’autres références que la page privée située derrière. Une réponse indisponible, un document non pris en charge ou une requête échouée laisse la vérification incomplète ; cela ne prouve pas l’absence de références non sécurisées.
Lire les ressources bloquables, les mises à niveau possibles et les formulaires
Utilisez le filtre de catégorie pour cibler la table, puis examinez l’élément et l’attribut à côté de chaque adresse. Les catégories décrivent le regroupement des références HTTP prises en charge par cet outil ; ce ne sont pas des comportements observés dans un navigateur.
| Catégorie | Exemples dans ce rapport | Point à examiner |
|---|---|---|
| Bloquable, rouge | Scripts, feuilles de style, cadres et candidats srcset d’images adaptatives |
Retrouvez la source et confirmez un remplacement HTTPS adapté. |
| Mise à niveau possible, jaune | Références prises en charge d’images, d’audio et de vidéo | Vérifiez que la ressource voulue fonctionne réellement en HTTPS ; une mise à niveau automatique ne prouve pas sa disponibilité. |
| Destination de formulaire non sécurisée, orange | action d’un formulaire ou formaction d’un bouton/input |
Confirmez la destination sécurisée prévue avant de modifier le formulaire. |
Le vérificateur examine aussi les références prises en charge des objets, champs de saisie de type image, affiches vidéo et certaines relations link. Les URL d’images ou de médias dont l’hôte est une adresse IP sont classées comme bloquables plutôt que comme pouvant être mises à niveau.
La documentation actuelle sur le contenu mixte distingue les requêtes pouvant être mises à niveau des requêtes bloquables. Le comportement réel dépend aussi des règles du navigateur et des politiques de sécurité. Cette classification du code source n’évalue pas toutes les exceptions, notamment les adresses locales potentiellement fiables. Une ligne rouge ne prouve donc pas qu’un navigateur précis a bloqué la requête.
Les destinations de formulaires constituent une catégorie distincte. La section sur les envois de formulaires de la spécification du contenu mixte traite les avertissements du navigateur séparément des vérifications ordinaires de ressources. Screpy n’envoie jamais ces formulaires et ne détermine pas les informations qu’ils recueillent. Examinez l’objectif du formulaire réel sans transmettre de données sensibles de test à une destination non vérifiée.
Retrouver les résultats groupés dans le code source
La table rassemble les occurrences ayant le même élément, attribut, classement et URL résolue. Une même adresse dans un autre élément ou attribut peut donc occuper une autre ligne. La ligne affichée correspond à la première occurrence du groupe dans le HTML récupéré, pas nécessairement à une ligne de votre éditeur de modèles.
Ce fragment fictif contient quatre références HTTP :
<script src="http://static.example.com/site.js"></script>
<img src="http://static.example.com/logo.png" alt="Example homepage">
<img src="http://static.example.com/logo.png" alt="Example homepage">
<form action="http://example.com/contact/" method="post"></form>
| Groupe | Occurrences | Classement |
|---|---|---|
script[src] se terminant par /site.js |
1 | Bloquable |
img[src] se terminant par /logo.png |
2 | Mise à niveau possible |
form[action] se terminant par /contact/ |
1 | Destination de formulaire non sécurisée |
Le résumé compte une référence bloquable, deux possibilités de mise à niveau et une référence de formulaire : quatre occurrences réparties en trois lignes. Cela ne signifie ni quatre fichiers uniques ni quatre requêtes réseau confirmées. L’exemple montre le regroupement du rapport, pas une analyse réelle ni un formulaire de contact complet et fonctionnel.
Retrouvez chaque occurrence d’une référence répétée dans le contenu ou le composant partagé responsable. Corriger uniquement la première ligne affichée peut en laisser une autre intacte. Examinez le texte source réel autour de cette ligne avant d’identifier le champ du CMS, le réglage du thème ou le modèle qui le produit.
Examiner les URL de base avant de modifier les chemins relatifs
L’URL de ressource affichée est résolue par rapport à la base effective du document. Sans base personnalisée, les chemins relatifs utilisent l’URL finale de la page. Un <base href> HTTP peut au contraire faire résoudre une référence relative en HTTP alors que la page a été récupérée en HTTPS.
Pour une page fictive à l’adresse https://example.com/guides/setup/, considérons ce fragment :
<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>
L’image se résout en http://static.example.com/assets/logo.png, pas en fichier sous le répertoire de la page HTTPS. Une référence relative au protocole telle que //static.example.com/assets/logo.png utilise également le schéma de la base. Retirer uniquement http: ne garantit donc pas une destination sécurisée.
La référence HTML de base explique comment la première base applicable détermine les URL relatives. Examinez ensemble la base et l’emplacement souhaité du fichier. La modifier peut affecter d’autres ressources, la navigation et les destinations des formulaires ; ne supprimez pas une base volontaire sans examiner ces effets. Une adresse HTTPS explicite et fonctionnelle peut clarifier le remplacement voulu.
Remplacer la référence non sécurisée par une destination HTTPS fonctionnelle
Commencez à l’endroit où la référence est générée. Une ancienne URL d’image peut se trouver dans un champ d’article, un réglage de logo ou un modèle partagé ; un script intégré peut venir du code fourni par une intégration. Corrigez cette source plutôt que du HTML généré que la prochaine publication remplacera. Évitez de remplacer globalement des chaînes http:// sans rapport dans tout le site.
Vérifiez la destination HTTPS proposée avant de l’utiliser. Elle doit fournir l’image, le script ou la ressource voulue sans redirection inattendue, écran d’accès ou contenu différent. Ce vérificateur n’a pas effectué cette requête. Passer http://static.example.com/site.js en HTTPS peut échouer si cet hôte ne fournit pas le même fichier de manière sécurisée.
Si une dépendance tierce n’a pas de version sécurisée adaptée, demandez un remplacement pris en charge ou décidez de retirer ou remplacer la fonction. Ne substituez pas discrètement un fichier sans rapport pour faire disparaître un résultat. Pour un formulaire, vérifiez le point de réception et le comportement attendu, pas seulement l’orthographe de l’adresse.
Une Content Security Policy contenant upgrade-insecure-requests peut modifier les requêtes du navigateur tout en laissant les références HTTP dans le code. Comme l’explique la documentation de la directive, une ressource HTTPS indisponible peut échouer sans revenir à HTTP. Cela ne prouve pas que toutes les ressources mises à niveau fonctionnent. Utilisez le vérificateur d’en-têtes HTTP pour examiner séparément les en-têtes déclarés ; ne remplacez pas aveuglément une politique existante et ne désactivez pas les protections du navigateur pour masquer le problème.
Vérifier la source publiée et les requêtes du navigateur
Conservez le rapport original et le remplacement prévu avant toute modification. Le téléchargement JSON garde les résultats et groupes retenus ; choisir une catégorie change la table, pas le téléchargement du rapport complet. Cet outil n’offre ni export CSV ni réparation automatique.
- Publiez le contenu, réglage ou modèle corrigé, puis vérifiez la même page HTTPS lorsque la réponse mise à jour est disponible.
- Comparez l’URL, l’élément, l’attribut et le nombre d’occurrences concernés. Un total plus bas peut masquer une autre référence restante ; examinez les lignes et pas seulement le résumé.
- Ouvrez la page dans un navigateur et examinez les avertissements de console et les requêtes réseau. Essayez l’image, le média ou la fonction concernée ; le rapport source n’exécute pas ces interactions.
- Vérifiez d’autres pages utilisant le modèle modifié. Une page d’accueil corrigée ne prouve pas que tous les produits ou articles le sont.
Le guide du panneau de sécurité de Chrome explique comment passer des origines non sécurisées aux requêtes réseau correspondantes. Les observations du navigateur peuvent révéler des requêtes produites par des scripts ou des styles que cet outil de source seule n’examine pas. Elles peuvent aussi montrer une requête mise à niveau ou bloquée alors que la source contient encore HTTP.
Gardez ces observations distinctes : une référence source corrigée et une requête réussie du navigateur répondent à deux questions différentes. Aucune ne prouve seule que tout le contenu, chaque navigateur ou tout le site est sécurisé.
Comprendre les résultats absents et la couverture partielle
Le vérificateur accepte jusqu’à 2 MiB de HTML et conserve jusqu’à 1 000 références HTTP réparties en 200 lignes groupées. Si une limite empêche de conserver davantage d’éléments, la couverture devient partielle et le total complet reste inconnu. Le résumé décrit alors la partie retenue, pas toutes les références du document. Une source impossible à récupérer ou dépassant la limite HTML rend plutôt la vérification indisponible.
L’absence de résultats signifie qu’aucune référence HTTP prise en charge n’a été trouvée dans le périmètre source examiné. Cela ne couvre pas les requêtes créées par JavaScript, les valeurs CSS url(), le contenu des feuilles de style externes, les documents de cadres imbriqués ni tous les attributs possibles. L’outil ne suit pas non plus les redirections de ressources : lire l’attribut initial d’un fichier HTTPS n’établit pas s’il redirige ensuite vers HTTP.
Les liens de navigation ordinaires sont exclus, y compris un lien normal vers une page HTTP. Le comportement des téléchargements et la sécurité de leur destination demandent une vérification séparée ; leur absence dans la table ne les approuve pas. Utilisez l’analyseur de liens internes pour les liens sortants plutôt que les ressources intégrées.
Pour un rapport partiel, conservez son périmètre avec le JSON et examinez séparément les références restantes. Retirer les lignes affichées ne prouve pas que les références omises sont corrigées. Relancez après modification et gardez l’ancien rapport afin de distinguer une correction confirmée d’éléments jamais vérifiés.