Mixed-Content-Prüfer

Zu prüfendes HTML

Erkennt http://-Ressourcen, die innerhalb einer HTTPS-Seite geladen werden.

Weiter

Nach der Migration einer Seite zu HTTPS brechen verwaiste <img>, <script>, <link> oder <iframe>-Tags, die weiterhin auf http://... verweisen, das grüne Vorhängeschloss und laden in modernen Browsern oft gar nicht. Gib eine URL ein und dieser Checker lädt die Seite, inspiziert jede Unterressource (Bilder, Stylesheets, Skripte, Schriftarten, iframes, Video, Audio) und listet alles auf, was über einfaches HTTP bereitgestellt wird, damit du sie beheben kannst, bevor die Nutzer eine “nicht vollständig sichere” Warnung erhalten.

Wie der Scan funktioniert

  1. 1

    Gib eine URL ein

    HTTPS-URL. Der Scanner folgt einem Umleitungs-Hops.

  2. 2

    Die Seite wird abgerufen

    HTML wird auf jede Unterressourcenreferenz geparst.

  3. 3

    Jede Referenz wird klassifiziert

    HTTPS, HTTP oder protokollrelativ (`//cdn...`).

  4. 4

    Bericht gruppiert nach Typ

    Aktiver vs. passiver Inhalt, mit Schweregrad-Ranking.

Aktiver vs. passiver gemischter Inhalt

Browser behandeln zwei Klassen unterschiedlich:

  • Aktiver gemischter Inhalt (Skripte, iframes, Stylesheets, XHR/fetch, Worker, WebSockets). Von modernen Browsern vollständig blockiert. Beinhaltet: <script>, <link rel="stylesheet">, <iframe>, fetch(), XMLHttpRequest, importScripts().
  • Passiver gemischter Inhalt (Bilder, Video, Audio-Poster). Wird geladen, aber markiert, das Vorhängeschloss fällt und die URL-Leiste zeigt eine Warnung an. Beinhaltet: <img>, <audio>, <video>, Formular action-Ziele.

Warum es wichtig ist

  • Vertrauen. Ein gebrochenes Vorhängeschloss signalisiert “diese Seite ist nicht sicher” an Nutzer, die es bemerken.
  • Funktionalität. Blockierter aktiver Inhalt bedeutet, dass Skripte nicht ausgeführt werden und Stylesheets nicht angewendet werden, Seiten sehen kaputt aus.
  • SEO. Google bevorzugt HTTPS-Seiten; gebrochenes HTTPS-Signal schadet indirekt den Rankings.
  • Compliance. PCI DSS und viele andere Compliance-Rahmenwerke erfordern HTTPS ohne gemischte Inhalte für Transaktionsseiten.

Häufige Quellen

Quelle Typische Lösung
Legacy CDN auf HTTP Domain auf HTTPS CDN umstellen
Eingebetteter YouTube / Vimeo alter Embed-Code Embed auf aktuelle Version aktualisieren
Ad-Netzwerk-Skript-URLs HTTPS-Version verwenden (seit Jahren verfügbar)
Drittanbieter-Schriftarten, Karten http://fonts.googleapis.comhttps:// umstellen
Social-Button-Widgets Aktuellen Widget-Code verwenden
Benutzergenerierte Bild-URLs Beim Speichern umschreiben; beim Anzeigen proxy-laden
Hardcodierte URLs in Blog-Beiträgen Batch-Suche und -Ersetzen in DB

Behebungsstrategien

  1. Protokoll-relative URLs (//cdn.example.com/a.js). Lädt mit dem Protokoll der aktuellen Seite. Sicher für die meisten CDNs, aber veraltet, bevorzuge https://... explizit.
  2. Im Quelltext umschreiben. Aktualisiere deine Vorlagen und Inhalte, um https:// zu verwenden. Scanne den Code mit einem Regex: http://(?!localhost).
  3. Content Security Policy-Upgrade. Content-Security-Policy: upgrade-insecure-requests sagt dem Browser, dass HTTP-Asset-URLs stillschweigend auf HTTPS umgeschrieben werden sollen. Am besten für Seiten, die nicht jede URL überprüfen können.
  4. <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> Inline-Äquivalent.
  5. HTTP-only Assets über deinen HTTPS-Ursprung proxy-laden, wenn der Upstream wirklich keinen HTTPS-Endpunkt hat (heute selten).

Was der Checker findet

  • Alle externen URLs, die in <img>, <script>, <link>, <iframe>, <video>, <audio>, <source> referenziert werden.
  • Formular action-Attribute.
  • Inline-CSS url(...)-Referenzen in <style>-Blöcken.
  • Scannt keine durch JavaScript geladenen Ressourcen, diese werden zur Laufzeit hinzugefügt und benötigen eine browserseitige Überprüfung (das Issues-Panel in Chrome DevTools erfasst diese).

Häufig gestellte Fragen

Teilweise. Der upgrade-insecure-requests CSP-Header oder Meta-Tag sagt den Browsern, dass sie HTTP-Unterressourcen-URLs automatisch auf HTTPS umschreiben sollen. Es funktioniert, wenn der Server HTTPS unterstützt; wenn der Upstream nur HTTP ist, schlägt die Umschreibung fehl.

Nein. Nur Ressourcen, die in statischem HTML referenziert werden. Skripte, die <img>-Elemente zur Laufzeit erstellen, werden nicht angezeigt. Das Issues-Panel von Chrome DevTools erfasst diese im Browser.

Sie sind auf HTTPS-Seiten gemischte Inhalts-sicher (sie erben HTTPS). Aber sie brechen auf HTTP-only internen Tools oder archivierten Seiten, und sie sind veraltet. Bevorzuge explizites https://.

Browser-Cache. Hartes Neuladen (Strg+Shift+R / Cmd+Shift+R) oder im Inkognito-Fenster testen, um die Behebung zu bestätigen. CSP-Berichte und Konsolenwarnungen zeigen den aktuellen Zustand.

Ein serverseitiger Abruf holt die Seite zur Analyse. Die URL selbst wird über die Anfrage hinaus nicht gespeichert.

Verwandte Tools

Tool in anderen Sprachen verfügbar