Mixed Content entsteht, wenn eine sicher geladene Seite Ressourcen über eine unsichere Verbindung anfordert. Screpys Mixed Content Checker findet HTTP-Ressourcenverweise im Quell-HTML einer öffentlichen HTTPS-Seite und zeigt Kategorie, Adresse, erste Quellzeile und Anzahl der Vorkommen. Damit können Sie den verantwortlichen Inhalt oder das Template finden und einen sicheren Ersatz vorbereiten.
Der Bericht führt die Seite nicht aus und ruft die aufgeführten Ressourcen nicht ab. Er nennt zu prüfende Quellverweise, dokumentiert aber nicht, was der Browser eines Besuchers tatsächlich geladen, auf HTTPS umgestellt oder blockiert hat. Eine erfolgreiche Prüfung bestätigt auch nicht die Sicherheit der gesamten Website.
Die HTTPS-Seite mit den Verweisen prüfen
Geben Sie die vollständige öffentliche Adresse der gewünschten Seite ein. Bei einem Artikel verwenden Sie dessen URL, etwa die beispielhafte https://example.com/guides/setup/, statt der Startseite oder eines verdächtigen Bildes. Das Tool untersucht eine angegebene Seite und entdeckt nicht alle Seiten der Domain.
Die Eingabe verlangt HTTPS. Lesen Sie anschließend die endgültige URL, denn Weiterleitungen können die untersuchte Seite ändern. Endet eine HTTPS-Adresse bei HTTP, ist die HTTPS-Mixed-Content-Analyse nicht anwendbar. Das ist kein unauffälliges Ergebnis. Untersuchen Sie unerwartete Ziele mit dem Redirect Checker.
Die Seite muss öffentlich lesbares HTML liefern. Ein Anmeldebildschirm kann andere Verweise enthalten als die geschützte Seite dahinter. Eine nicht verfügbare Antwort, ein nicht unterstütztes Dokument oder ein fehlgeschlagener Abruf lässt die gewünschte Prüfung offen und beweist nicht, dass keine unsicheren Verweise existieren.
Blockierbare Ressourcen, Upgrade-Kandidaten und Formularziele lesen
Grenzen Sie die Tabelle mit dem Kategoriefilter ein und prüfen Sie Element und Attribut neben jeder Adresse. Die Kategorien beschreiben die Einordnung unterstützter HTTP-Verweise durch dieses Tool, keine beobachteten Browserergebnisse.
| Kategorie | Beispiele im Bericht | Was zu prüfen ist |
|---|---|---|
| Blockierbar, rot | Skripte, Stylesheets, Frames, responsive Bildkandidaten in srcset |
Quelle finden und einen geeigneten HTTPS-Ersatz bestätigen. |
| Upgrade-Kandidat, gelb | Unterstützte Bild-, Audio- und Videoquellen | Prüfen, ob die beabsichtigte Ressource über HTTPS funktioniert; eine automatische Umstellung beweist keine Verfügbarkeit. |
| Unsicheres Formularziel, orange | action eines Formulars oder formaction von Button/Input |
Vor Änderungen das beabsichtigte sichere Übermittlungsziel bestätigen. |
Der Checker untersucht auch unterstützte Verweise von Objekten, Bildeingaben, Video-Postern und ausgewählten Link-Beziehungen. Bild- oder Medien-URLs mit einer IP-Adresse als Host werden als blockierbar statt als Upgrade-Kandidaten eingeordnet.
Die aktuelle Mixed-Content-Dokumentation unterscheidet umstellbare und blockierbare Anfragen. Das tatsächliche Verhalten hängt auch von Browserregeln und Sicherheitsrichtlinien ab. Diese Quellklassifizierung berücksichtigt nicht jede Ausnahme, etwa potenziell vertrauenswürdige lokale Adressen. Eine rote Zeile beweist daher nicht, dass ein bestimmter Browser die Anfrage blockiert hat.
Formularziele sind eine eigene Prüfkategorie. Der Abschnitt zu Formularübermittlungen in der Mixed-Content-Spezifikation behandelt Browserwarnungen getrennt von gewöhnlichen Ressourcenprüfungen. Screpy sendet die Formulare nicht ab und ermittelt nicht, welche Informationen sie sammeln. Prüfen Sie den Zweck eines echten Formulars, ohne sensible Testdaten an ein ungeprüftes Ziel zu senden.
Gruppierte Befunde zur Quelle zurückverfolgen
Die Tabelle fasst Vorkommen mit gleichem Element, Attribut, gleicher Klassifizierung und aufgelöster URL zusammen. Dieselbe Adresse in einem anderen Element oder Attribut kann deshalb eine weitere Zeile bilden. Die angezeigte Zeile bezeichnet das erste Vorkommen der Gruppe im abgerufenen HTML, nicht zwingend eine Zeile im Template-Editor.
Dieses fiktive Fragment enthält vier HTTP-Verweise:
<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>
| Gruppe | Vorkommen | Klassifizierung |
|---|---|---|
script[src] mit Ende /site.js |
1 | Blockierbar |
img[src] mit Ende /logo.png |
2 | Upgrade-Kandidat |
form[action] mit Ende /contact/ |
1 | Unsicheres Formularziel |
Die Zusammenfassung zählt einen blockierbaren Verweis, zwei Upgrade-Kandidaten und einen Formularverweis: vier Vorkommen in drei Zeilen. Das bedeutet weder vier eindeutige Dateien noch vier bestätigte Netzwerkanfragen. Das Beispiel erklärt die Gruppierung; es ist kein Live-Scan und kein vollständiges funktionierendes Kontaktformular.
Suchen Sie jedes Vorkommen eines wiederholten Verweises im verantwortlichen Inhalt oder gemeinsamen Baustein. Nur die erste angezeigte Zeile zu korrigieren kann eine weitere unverändert lassen. Prüfen Sie den tatsächlichen Quelltext um diese Stelle, bevor Sie das zuständige CMS-Feld, die Theme-Einstellung oder das Template bestimmen.
Basis-URLs vor Änderungen relativer Pfade prüfen
Die angezeigte Ressourcen-URL wird gegen die effektive Dokumentbasis aufgelöst. Ohne eigene Basis verwenden relative Pfade die endgültige Seiten-URL. Ein HTTP-<base href> kann einen relativen Verweis dagegen auf HTTP auflösen, obwohl die Seite über HTTPS abgerufen wurde.
Für eine fiktive Seite unter https://example.com/guides/setup/ betrachten Sie dieses Fragment:
<head><base href="http://static.example.com/assets/"></head>
<body><img src="logo.png" alt="Example homepage"></body>
Das Bild wird als http://static.example.com/assets/logo.png aufgelöst, nicht als Datei unter dem Verzeichnis der HTTPS-Seite. Ein protokollrelativer Verweis wie //static.example.com/assets/logo.png verwendet ebenfalls das Schema der Basis. Nur http: zu entfernen stellt daher kein sicheres Ziel sicher.
Die HTML-base-Referenz erklärt, wie die erste anwendbare Basis relative URLs steuert. Prüfen Sie Basis und beabsichtigten Dateipfad gemeinsam. Eine Änderung kann weitere Ressourcen, Navigation und Formularziele betreffen. Entfernen Sie eine absichtliche Basis nicht ohne diese Folgen zu prüfen. Eine ausdrückliche, funktionierende HTTPS-Ressourcenadresse kann den gewünschten Ersatz klarer machen.
Den unsicheren Verweis durch ein funktionierendes HTTPS-Ziel ersetzen
Beginnen Sie dort, wo der Verweis erzeugt wird. Eine alte Bildadresse kann in einem Artikelfeld, einer Logo-Einstellung oder einem gemeinsamen Template stehen; ein eingebettetes Skript kann aus dem Code einer Integration stammen. Korrigieren Sie diese Quelle statt erzeugtes HTML, das bei der nächsten Veröffentlichung überschrieben wird. Ersetzen Sie nicht pauschal alle unzusammenhängenden http://-Zeichenfolgen der Website.
Prüfen Sie das vorgeschlagene HTTPS-Ziel vor der Verwendung. Es sollte das richtige Bild, Skript oder die andere beabsichtigte Ressource liefern, ohne unerwartete Weiterleitung, Zugriffssperre oder fremden Inhalt. Dieser Checker hat den Abruf nicht durchgeführt. Die Umstellung von http://static.example.com/site.js auf HTTPS kann scheitern, wenn der Host dieselbe Datei nicht sicher bereitstellt.
Hat eine externe Abhängigkeit keine geeignete sichere Version, fragen Sie nach einem unterstützten Ersatz oder entscheiden Sie, ob die Funktion entfernt oder ersetzt werden soll. Tauschen Sie nicht still eine unpassende Datei ein, um einen Befund zu beseitigen. Prüfen Sie bei Formularen den empfangenden Endpunkt und das erwartete Verhalten, nicht nur die Schreibweise.
Eine Content Security Policy mit upgrade-insecure-requests kann Browseranfragen verändern, während HTTP-Verweise im Quelltext bleiben. Laut Dokumentation der Direktive kann eine nicht verfügbare HTTPS-Ressource fehlschlagen, ohne auf HTTP zurückzufallen. Das beweist nicht, dass jede umgestellte Ressource funktioniert. Prüfen Sie deklarierte Antwortheader separat mit dem HTTP Headers Checker. Ersetzen Sie eine bestehende Richtlinie nicht blind und deaktivieren Sie keine Browserschutzfunktionen, um das Problem zu verbergen.
Veröffentlichten Quelltext und Browseranfragen verifizieren
Bewahren Sie den ursprünglichen Bericht zusammen mit dem vorgesehenen Ersatz auf. Der JSON-Download enthält die behaltenen Befunde und Gruppen; ein Kategoriefilter verändert die Tabelle, nicht den vollständigen Berichtsdownload. Dieses Tool bietet weder CSV-Export noch automatische Reparatur.
- Veröffentlichen Sie den korrigierten Inhalt, die Einstellung oder das Template und prüfen Sie dieselbe HTTPS-Seite erneut, sobald die aktuelle Antwort verfügbar ist.
- Vergleichen Sie URL, Element, Attribut und Vorkommenszahl. Eine kleinere Summe kann einen anderen verbliebenen Verweis verbergen; lesen Sie die Zeilen statt nur die Zusammenfassung.
- Öffnen Sie die Seite im Browser und prüfen Sie Warnungen in der Entwicklerkonsole und die Netzwerkanfragen. Nutzen Sie das betreffende Bild, Medium oder die Funktion; der Quellbericht führt solche Interaktionen nicht aus.
- Prüfen Sie weitere Seiten mit demselben geänderten Template. Eine reparierte Startseite beweist keine Korrektur aller Produkte oder Artikel.
Chromes Anleitung zum Sicherheitsbereich beschreibt den Weg von unsicheren Ursprüngen zu den zugehörigen Netzwerkanfragen. Browserbeobachtungen können Anfragen aus Skripten oder Styles zeigen, die dieses reine Quellwerkzeug nicht untersucht. Sie können auch eine umgestellte oder blockierte Anfrage zeigen, obwohl im Originalquelltext noch HTTP steht.
Halten Sie diese Beobachtungen auseinander: Ein korrigierter Quellverweis und eine erfolgreiche Browseranfrage beantworten unterschiedliche Fragen. Keines von beiden beweist allein, dass alle Inhalte, jeder Browser oder die gesamte Website sicher sind.
Fehlende Befunde und teilweise Abdeckung verstehen
Der Checker akzeptiert bis zu 2 MiB HTML und behält bis zu 1.000 HTTP-Verweise in 200 gruppierten Zeilen. Verhindert eine Ergebnisgrenze weitere Erfassung, wird die Abdeckung teilweise und die vollständige Verweiszahl bleibt unbekannt. Die Zusammenfassung beschreibt dann den behaltenen Ausschnitt. Bei einem nicht abrufbaren oder zu großen HTML-Quelltext ist die gewünschte Prüfung dagegen nicht verfügbar.
Keine Befunde bedeutet, dass im untersuchten Quellumfang keine unterstützten HTTP-Verweise gefunden wurden. Nicht abgedeckt sind JavaScript-Anfragen, CSS-url()-Werte und die Inhalte externer Stylesheets oder verschachtelter Frame-Dokumente. Auch wird nicht jedes mögliche Ressourcenattribut untersucht. Ressourcenweiterleitungen werden ebenfalls nicht verfolgt: Ein HTTPS-Asset, das später auf HTTP umleitet, lässt sich nicht aus seinem ursprünglichen Attribut feststellen.
Normale Navigationsanker sind ausgeschlossen, auch gewöhnliche Links zu HTTP-Seiten. Downloadverhalten und Zielsicherheit müssen separat geprüft werden; das Fehlen in dieser Tabelle ist keine Freigabe. Verwenden Sie den Internal Link Analyzer, wenn Ihre Frage ausgehende Links statt eingebetteter Ressourcen betrifft.
Sichern Sie bei einem Teilbericht dessen Umfang mit dem JSON-Download und untersuchen Sie übrige Quellverweise separat. Das Entfernen angezeigter Zeilen beweist keine Reparatur ausgelassener Verweise. Wiederholen Sie die Prüfung und behalten Sie den früheren Bericht, um bestätigte Korrekturen von nie geprüfter Evidenz unterscheiden zu können.