Dois-je m'inquiéter du fait que Google Ads affiche parfois un contenu mixte passif (images non sécurisées) dans certaines annonces?
Dans certaines pages comportant des annonces Google Ads, Chrome la console Dev Tools affiche l'avertissement relatif à contenu mixte passif :
Contenu mixte: La page "..." a été chargée via HTTPS, mais une image non sécurisée a été demandée.
Mon site n'est pas HTTPS et je ne pouvais évidemment pas contrôler les images diffusées par les annonces. Si j'utilise
Content-Security-Policy: block-all-mixed-content
, les annonces risquent de ne pas être diffusées. Va ajouter
Content-Security-Policy: upgrade-insecure-requests
être une bonne idée, ou devrais-je même être préoccupé par cela?
Commencez par déplacer votre site vers https car à partir de juillet 2018, Google chrome a commencé à marquer les sites HTTP comme non sécurisés et je pense que d'autres navigateurs feront de même. Lien vers les nouvelles officielles
En ce qui concerne le CSP, je vous conseillerais d’utiliser Content-Security-Policy: upgrade-insecure-requests. Cela demande une ressource https et si non disponible, la demande échoue et la ressource n'est pas chargée.
Pourquoi ne pas utiliser Content-Security-Policy: block-all-mixed-content - nous commettrons des erreurs de temps en temps jusqu'à ce que tout le monde soit captivé par HTTPS et que personne n'utilise plus le protocole HTTP. Votre favicon, logo ou autre ressource peut appeler une requête HTTP de temps en temps, ce qui peut bloquer votre contenu principal.
upgrade-insecure-requests nous offre une alternative au blocage immédiat plutôt qu’à la demande d’une ressource sécurisée.
Hypothèse: votre site ne demande pas trop de plugins ou de scripts tiers, ni un moteur qui appelle des scripts tiers pour afficher le contenu sur votre site Web. Si tel est le cas, prenez toutes les précautions et utilisez block-all-mixed-content
Je pense que ce sujet est déjà couvert de manière adéquate ailleurs sur Internet.
Je soupçonne que si vous utilisez un nouveau code d'annonce, le protocole n'est pas spécifié dans le code suivant cet exemple .
Je suppose mais je ne peux pas prouver que si vous réinsérez http dans le code où il manque avant //, alors vous pouvez trouve que cela résout le problème. C'est certainement un bug-bear lors de la navigation.
Je mettrai à jour la réponse s'il y a des commentaires.