Was „Mixed Content" bedeutet und warum der Browser Ihr Bild blockiert hat

Sie haben eine Seite über HTTPS geladen, das Schloss ist in der Adressleiste sichtbar, und dennoch fehlt ein Bild, ein Skript wurde nicht ausgeführt oder ein ganzes Widget ist nicht erschienen. Öffnen Sie die Konsole und dort steht es: „Mixed Content: Die Seite wurde über HTTPS geladen, aber es wurde eine unsichere Ressource über HTTP angefordert. Diese Anfrage wurde blockiert.”

Die Seite ist sicher. Etwas, das sie angefordert hat, war es nicht, und der Browser hat sich geweigert, es abzurufen. Das ist das Ganze eines Mixed-Content-Fehlers, und die Korrektur ist normalerweise ein Zeichen - aber es hilft zu verstehen, warum der Browser so streng mit einem einzigen fehlenden Bild umgeht.

Was „gemischt” hier bedeutet

Eine über HTTPS bereitgestellte Seite wird verschlüsselt übermittelt, und das Schloss ist ein Versprechen an den Besucher, dass alles so angekommen ist. Dann fordert die Seite eine Ressource an - ein Bild, ein Skript, ein Stylesheet, eine Schriftart - unter Verwendung einer einfachen http://-Adresse. Diese Ressource würde unverschlüsselt ankommen, über eine Verbindung, die jeder im Netzwerk lesen oder manipulieren kann.

Das ist die Mischung: eine sichere Seite und eine unsichere Anfrage darin. Der Browser wird das Versprechen des Schlosses nicht stillschweigend brechen, daher greift er ein. Was er als Nächstes tut, hängt davon ab, wie gefährlich die Ressource ist.

Blockiert oder nur gewarnt

Nicht alle Mixed-Content-Fehler werden gleich behandelt, und dieser Teil erklärt, warum manchmal ein Bild mit einer Warnung geladen wird und manchmal ein Skript völlig verschwindet.

Aktive Inhalte werden vollständig blockiert. Skripte, Stylesheets, iframes und alles, das die Seite ändern oder Code ausführen kann. Wenn einer dieser Inhalte über HTTP angefordert wird, weigert sich der Browser, ihn überhaupt zu laden, da ein manipuliertes Skript die ganze Seite umschreiben könnte. Das ist dasjenige, das Funktionen bricht: ein Zahlungs-Widget, ein Analytics-Tag, eine Karte, die nie erscheint.

Passive Inhalte werden geladen, mit einer Warnung oder aufgewertet. Bilder, Video und Audio - Dinge, die angezeigt werden, aber keinen Code ausführen können. Ältere Browser luden diese über HTTP und degradierten das Schloss, um Sie zu warnen. Moderne Browser versuchen zunehmend, sie stattdessen über HTTPS abzurufen, und schlagen nur offensichtlich fehl, wenn das nicht funktioniert. Ein fehlendes Bild und ein totes Skript sind also oft derselbe zugrunde liegende Fehler, der sich mit unterschiedlichem Schweregrad zeigt.

So finden und beheben Sie es

Die Konsole nennt die genaue Ressource. Lesen Sie die URL, über die sie sich beschwert, und die Korrektur besteht fast immer darin, diese Ressource über https:// statt über http:// anzufordern.

• Wenn die Ressource eine HTTPS-Version hat, verwenden Sie diese. Die meisten haben eine; das Ändern von http:// zu https:// in Ihrem eigenen Markup ist die ganze Korrektur. Wenn Sie viele haben, behebt eine protokollrelative //example.com/... oder eine content-security-policy-Direktive upgrade-insecure-requests sie in Menge.
• Wenn die Ressource keine HTTPS-Version hat, können Sie sie nicht einbeziehen. Ein Drittanbieter-Asset, das nur über HTTP bereitgestellt wird, muss ersetzt, durch Ihren eigenen HTTPS-Server als Proxy geleitet oder gelöscht werden. Es gibt keine Browser-Einstellung, die dies sicher macht, und einem Besucher zu sagen, er solle den Schutz deaktivieren, ist keine Korrektur.
• Achten Sie darauf in Daten, nicht nur im Markup. Eine URL, die in Ihrer Datenbank gespeichert ist, von einer API zurückgegeben wird oder in ein Rich-Text-Feld eingefügt wird, ist der gewöhnliche Grund, warum Mixed Content eine Migration zu HTTPS überlebt: die Vorlagen wurden korrigiert, der Inhalt aber nicht.

Eine Anfrage, die auf diese Weise fehlschlägt, sieht viel wie eine aus, die aus anderen Gründen fehlgeschlagen ist, weshalb die Konsolenzeile wichtig ist. Wenn die Konsole stattdessen sagt, dass die Anfrage durch die CORS-Richtlinie blockiert wurde, oder zurückkommt als TypeError: Failed to fetch, das ist ein anderes Problem mit einer anderen Korrektur - das erste Wort des Fehlers leistet viel Arbeit.

Warum ein Screenshot nicht ausreicht, um eine zu melden

Ein Mixed-Content-Fehler ist in einem Screenshot unsichtbar: Die Seite hat einfach eine Lücke, wo etwas sein sollte, und der Grund befindet sich in der Konsole, die die Person, die es meldet, sehr wahrscheinlich nicht geöffnet hat. „Das Bild fehlt” und „das Checkout-Widget wurde nicht geladen” sind die Berichte, die Sie erhalten, und keiner von ihnen enthält die Konsolenzeile, die genau angibt, welche HTTP-Ressource auf einer HTTPS-Seite abgelehnt wurde.

Das Konsolenprotokoll, das es erfasst, ist der Ort, an dem die Mixed-Content-Nachricht mit der benannten Ressource lebt, sodass jeder, der den Bericht aufgreift, sehen kann, welche unsichere URL zu beheben ist, ohne die Seite reproduzieren und Entwickler-Tools öffnen zu müssen, um sie zu finden.

In einem Absatz

Mixed Content ist eine unsichere http://-Ressource, die von einer sicheren https://-Seite angefordert wird, und der Browser blockiert sie - vollständig für Skripte und andere aktive Inhalte, schonender für Bilder - eher als das Versprechen zu brechen, das das Schloss macht. Die Korrektur besteht fast immer darin, die Ressource über HTTPS anzufordern, sowohl in Ihrem Markup als auch in Ihren gespeicherten Daten; wenn es keine HTTPS-Version hat, kann es überhaupt nicht sicher eingebunden werden. Und da der Fehler ein stilles Loch auf der Seite mit der Begründung in der Konsole ist, lohnt es sich, ihn zu erfassen, anstatt ihn zu beschreiben.