Warnung vor Mixed Content nach der Aktivierung von HTTPS

Was dieser Fehler bedeutet und wie du ihn erkennst

• Die Seitenadresse verwendet HTTPS, aber die Entwicklerwerkzeuge des Browsers melden Mixed Content.
• Ein Script, Stylesheet, eine Schriftart, ein Bild, Video, Hintergrundbild oder eingebetteter Frame wird nach der Aktivierung von HTTPS nicht geladen oder verhält sich anders.
• Meldungen in der Console identifizieren eine HTTP-Ressource, die von einer HTTPS-Seite angefordert wird.
• Die Funktionalität der Seite ist unvollständig, weil aktive Inhalte wie JavaScript oder CSS blockiert werden.
• Die Warnung erscheint nur auf bestimmten Seiten, in bestimmten Templates oder bei bestimmten Benutzerzuständen. Das deutet auf einen fest codierten oder bedingt erzeugten Verweis hin.
• Das Zertifikat der Website scheint für die Hauptseite gültig zu sein, obwohl einzelne Ressourcen weiterhin unsichere Verweise verwenden.

Hauptursachen nach Wahrscheinlichkeit

1. Fest codierte HTTP-Verweise: Seiteninhalte, Templates, Theme-Dateien, Widgets oder Stylesheets verweisen weiterhin auf eine Ressource mit einer http://-Adresse.
2. Alte gespeicherte Inhalte: Bilder, Einbettungen, Medienfelder, Scripts oder andere Datenbankwerte enthalten noch HTTP-Verweise aus der Zeit vor der HTTPS-Migration.
3. Ausgabe von Theme oder Plugin: Eine Komponente erzeugt eine unsichere URL, obwohl die Hauptadresse der Website für HTTPS konfiguriert ist.
4. Externe Ressourcen ohne HTTPS-Unterstützung: Ein Script, eine Schriftart, ein Frame, eine Mediendatei oder eine andere Abhängigkeit eines Drittanbieters ist möglicherweise nicht sicher verfügbar.
5. Gecachte oder gebündelte Dateien: Seiten-Caches, Asset-Bundles, minimierte Dateien, CDNs oder Reverse-Proxys liefern möglicherweise noch Markup mit einem älteren Verweis aus.
6. Veraltete Anwendungs- oder Asset-Konfiguration: Die Anwendung erstellt absolute URLs möglicherweise anhand einer alten Basisadresse oder Umgebungseinstellung.

Eine Mixed-Content-Warnung zeigt für sich genommen nicht, dass das Zertifikat der Website ungültig ist. Ein Zertifikatsfehler betrifft die sichere Verbindung zur Website oder zum Host der Ressource; Mixed Content betrifft unsichere Ressourcen, die innerhalb einer ansonsten sicheren Seite angefordert werden.

So behebst du den Fehler

1. Bestätigen, dass es sich um Mixed Content handelt

Öffnen Sie die betroffene Seite in einem aktuellen Browser und öffnen Sie die Entwicklerwerkzeuge. Suchen Sie in der Console nach Mixed-Content-Meldungen. Prüfen Sie im Network-Panel die in der Warnung genannte Anfrage und notieren Sie URL, Ressourcentyp, Status sowie – sofern angezeigt – die Datei oder Komponente, von der die Anfrage initiiert wurde.

Kann der Browser keine sichere Verbindung zur Hauptseite herstellen und zeigt eine Zertifikatswarnung an, behandeln Sie dies als separates Problem. Ändern Sie keine Zertifikatseinstellungen, um einen unsicheren Ressourcenverweis zu beheben.

2. Alle unsicheren Verweise identifizieren

Untersuchen Sie die gerenderte Seite und gegebenenfalls ihren Quelltext, Stylesheets, Scripts und generierten Asset-Dateien auf HTTP-Verweise. Prüfen Sie nicht nur sichtbare Bilder: Auch JavaScript, CSS, Schriftarten, Frames, Medien und CSS-Hintergrundbilder können Warnungen oder Ladefehler verursachen.

Testen Sie die betroffene Seite in einem privaten Browserfenster oder nachdem Sie den relevanten Browser-Cache geleert haben. So können Sie eine aktuelle unsichere Anfrage von einer alten, gecachten Antwort unterscheiden. Das Ersetzen des ursprünglichen Verweises wird dadurch jedoch nicht überflüssig.

3. Die Quelle ermitteln, die den Verweis erzeugt

Grenzen Sie anhand des Ressourcentyps und der betroffenen Seiten ein, woher die URL stammt:

• Eine einzelne Seite oder ein Artikel: Prüfen Sie dessen gespeicherten Inhalt oder das Medienfeld.
• Mehrere Seiten mit demselben Layout: Prüfen Sie das gemeinsame Template, Theme, Widget oder die wiederverwendbare Komponente.
• Nur Seiten mit einer bestimmten Funktion: Prüfen Sie das zuständige Plugin, die Integration, Einbettung oder Konfigurationseinstellung.
• Eine Anfrage für ein kombiniertes Asset: Prüfen Sie das Quell-Stylesheet, Script, den Build-Prozess, Cache oder Proxy, der das Bundle erzeugt hat.
• Unterschiedliches Verhalten bei angemeldeten und abgemeldeten Besuchern: Vergleichen Sie die für die jeweiligen Zustände gerenderten Inhalts- und Caching-Ebenen.

4. Den Verweis an seiner Quelle aktualisieren

Wenden Sie die passende Korrektur für den Ort an, an dem der Verweis gespeichert ist:

• Ändern Sie Seiten- oder Beitragsinhalte so, dass sie die HTTPS-Version der Ressource verwenden.
• Aktualisieren Sie die Einstellung für Website, Medien, Theme, Plugin, Einbettung oder Integration, die die URL erzeugt.
• Korrigieren Sie fest codierte Verweise in Templates, Stylesheets, Scripts oder Konfigurationsdateien.
• Verwenden Sie für eine same-site-Ressource einen unterstützten relativen Pfad, sofern dies zur Struktur der Anwendung und des Deployments passt.
• Prüfen Sie bei einer externen Ressource, ob ihr Host HTTPS unterstützt. Falls nicht, ersetzen Sie die Abhängigkeit durch eine sichere Quelle oder entfernen Sie sie – insbesondere, wenn sie aktive Inhalte bereitstellt.

5. Globale Ersetzungen nur mit Sicherheitsvorkehrungen verwenden

Eine globale Ersetzung ist geeignet, wenn derselbe veraltete Wert in vielen bekannten Datensätzen gespeichert ist. Holen Sie vor Änderungen an Produktionsdaten eine Genehmigung ein, erstellen Sie ein wiederherstellbares Backup, definieren Sie den genauen Umfang und testen Sie den Vorgang nach Möglichkeit an einer Staging-Kopie oder repräsentativen Datensätzen.

Berücksichtigen Sie serialisierte oder strukturierte Daten und ersetzen Sie nicht blind jedes Vorkommen einer Zeichenfolge. Prüfen Sie externe Hosts, Weiterleitungen, Dateipfade, Konfigurationswerte und Datensätze, in denen der Text http:// möglicherweise keine Seiten-URL darstellt. Wenn Sie die Datenstruktur nicht kennen, bitten Sie den Betreiber der Anwendung oder einen Entwickler, die Änderung durchzuführen.

6. Generierte und gecachte Inhalte leeren

Leeren Sie nach der Korrektur der Quelle die Anwendungs-, Seiten-, CDN-, Reverse-Proxy- und Browser-Caches, die noch altes Markup oder Asset-Bundles enthalten können. Generieren Sie kombinierte oder minimierte Assets neu, sofern die Website solche verwendet. Führen Sie nur Cache-Leerungen durch, die für die betroffene Umgebung autorisiert sind, da sie den Traffic zum Origin-Server vorübergehend erhöhen oder das Verhalten der Website ändern können.

7. Die Reparatur überprüfen

Laden Sie die betroffenen Seiten neu und prüfen Sie die Console sowie das Network-Panel erneut. Bestätigen Sie, dass die zuvor gemeldete Ressource sicher angefordert wird, Scripts und Styles funktionieren und keine neuen unsicheren Verweise erscheinen.

Wiederholen Sie die Prüfung für verwandte Templates sowie relevante Ansichten für angemeldete und abgemeldete Besucher. Wenn die Warnung nach einer Cache-Aktualisierung zurückkehrt, müssen das zugrunde liegende Template, Plugin, die Konfiguration oder das generierte Asset weiterhin korrigiert werden.

Vorbeugung und Überprüfung der Lösung

• Fügen Sie Bilder, Scripts, Stylesheets, Schriftarten, Einbettungen und Medien mit HTTPS-kompatiblen Verweisen ein.
• Halten Sie die Website-Adresse der Anwendung, Asset-Einstellungen, das Theme, Plugins und Integrationen konsistent mit HTTPS.
• Prüfen Sie Abhängigkeiten von Drittanbietern vor dem Deployment und ersetzen Sie Anbieter, die keine sichere Auslieferung ermöglichen.
• Nehmen Sie Prüfungen auf Mixed Content in Staging- und Migrationstests auf.
• Prüfen Sie gemeinsame Templates und wiederverwendbare Komponenten, nicht nur die Seite, auf der die Warnung zuerst gefunden wurde.
• Erstellen Sie vor umfangreichen Inhaltsänderungen getestete Backups und leeren oder regenerieren Sie anschließend die betroffenen Caches und Asset-Bundles.
• Prüfen Sie Seiten mit unterschiedlichen Authentifizierungszuständen erneut, wenn sie unterschiedliche Ressourcen rendern.

Häufig gestellte Fragen