Pourquoi une seule image http:// compromet-elle la sécurité de toute la page, pas seulement cette image ?

Parce que cette seule requête est non chiffrée et non authentifiée, un attaquant sur le même réseau (wifi public, routeur compromis) peut l'intercepter ou la modifier en transit - et selon ce qu'elle est (un script, en particulier), cela peut compromettre le reste de la page même si tout le reste s'est chargé correctement en HTTPS.

Le navigateur bloque-t-il automatiquement le contenu mixte, ou se contente-t-il d'avertir ?

Cela dépend du type de ressource. Le contenu mixte « actif » - scripts, feuilles de style, iframes - est bloqué purement et simplement par les navigateurs modernes. Le contenu mixte « passif » - images, vidéo, audio - est généralement quand même chargé mais déclenche un avertissement de cadenas cassé dans la barre d'adresse, exactement le genre de signal de confiance qui fait hésiter les visiteurs.

Comment Scanverra trouve-t-il le contenu mixte - se contente-t-il de scanner mon HTML pour des liens http:// ?

Non, c'est plus robuste que cela. Scanverra charge la page dans un véritable navigateur et capture les requêtes réseau réelles que la page effectue, puis signale toute requête commençant par http:// sur une page servie en https. Cela détecte les ressources chargées dynamiquement par JavaScript, pas seulement celles codées en dur dans votre balisage.

Puis-je simplement ajouter upgrade-insecure-requests et arrêter de me soucier des URL individuelles ?

Cela aide comme filet de sécurité - cela indique au navigateur de réécrire automatiquement les requêtes http:// en https:// avant de les envoyer - mais cela ne fonctionne que si la ressource est réellement disponible en HTTPS sur ce même hôte. C'est un bon filet de sécurité, pas un substitut à la correction des URL codées en dur.

Comment corriger les avertissements de contenu mixte

Le contenu mixte se produit lorsqu'une page servie en HTTPS charge ne serait-ce qu'une seule ressource - un script, une image, une feuille de style, une iframe - en HTTP simple à la place. Cette seule requête non chiffrée compromet la garantie de sécurité que le reste de la page était censée offrir, et les navigateurs réagissent en bloquant la ressource, en cassant l'icône du cadenas, ou les deux.

Pourquoi le contenu mixte apparaît

Des URL http:// codées en dur, restantes d'avant une migration HTTPS. D'anciens balisages, du contenu CMS, ou une base de données d'URL d'assets stockées écrites à l'époque où le site tournait en HTTP simple et jamais mises à jour.
Des embeds et widgets tiers encore servis en HTTP. Un réseau publicitaire, un widget de commentaires, ou un ancien snippet d'analytics qui n'a jamais migré sa propre livraison vers HTTPS.
Des URL de CDN ou d'hébergeur d'assets oubliées lors d'une migration de protocole. Le domaine principal est passé en HTTPS, mais un sous-domaine ou un hébergeur d'assets tiers servant des images ou des polices n'a pas été mis à jour en même temps.
Du contenu généré par les utilisateurs avec des liens HTTP collés. Un utilisateur soumet du contenu (un message de forum, un avis produit, un champ CMS) contenant une URL d'image ou d'embed en http:// qui est rendue telle quelle.

Comment identifier chaque occurrence

Scanverra détecte le contenu mixte en chargeant votre page dans un véritable navigateur et en capturant son activité réseau réelle - à la fois le Browser Test et le scan de sécurité signalent toute requête commençant par http:// alors que la page elle-même est servie en HTTPS. Comme cela repose sur de véritables requêtes réseau capturées plutôt que sur une analyse statique de votre code source HTML, cela détecte les ressources chargées dynamiquement par JavaScript après le rendu de la page, pas seulement celles codées en dur directement dans votre balisage.

Comment le corriger

1. Remplacez les URL http:// codées en dur par des https://

Avant : une URL d'image http:// codée en durtypescript

1<img src="http://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

Après : servie en https, ou en protocole relatif si l'hôte prend en charge les deuxtypescript

1<img src="https://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

2. Ajoutez upgrade-insecure-requests comme filet de sécurité

Cette directive CSP indique au navigateur de réécrire automatiquement toute requête http:// restante en https:// avant de l'envoyer, rattrapant les URL que vous avez manquées - même si cela ne fonctionne que si la ressource est réellement accessible en HTTPS sur cet hôte :

Mettre à niveau automatiquement toute requête http:// égarée vers https://typescript

1Content-Security-Policy: upgrade-insecure-requests

3. Auditez spécifiquement les embeds tiers

Les scripts et widgets tiers sont la source la plus fréquente de contenu mixte que vous ne contrôlez pas directement - vérifiez la documentation de chacun pour une URL d'embed HTTPS, et supprimez ceux qui n'en proposent pas.

4. Assainissez ou réécrivez le protocole dans le contenu soumis par les utilisateurs

Si les utilisateurs peuvent soumettre du contenu contenant des URL, réécrivez http:// en https:// au moment du rendu (ou rejetez la soumission) plutôt que de rendre le protocole tel qu'il a été collé.

Comment Scanverra détecte cela

À la fois le Browser Test et le scan de sécurité de Scanverra capturent les véritables requêtes réseau de votre page dans un navigateur en direct et signalent toute requête commençant par http:// sur une page servie en HTTPS - une véritable vérification à l'exécution du trafic réel, pas une recherche textuelle dans votre code source.