Mixed Content: http://-Reste in Ihrer https://-Seite

Warum ein vergessenes Bild oder Skript über http:// die Sicherheit einer HTTPS-Seite aushebelt, was Browser blockieren oder still auf https umstellen und wie Sie dauerhaft aufräumen.

Sicherheit · Veröffentlicht: 25. September 2026 · 6 Min. Lesezeit · Дмитрий Орлов

Eine Website auf HTTPS umzustellen dauert einen Nachmittag: Zertifikat besorgen, Port 80 umleiten, fertig. Und dann fehlt auf der Hälfte der Seiten das Schloss, ein Slider funktioniert nicht mehr oder eine Schrift fällt stillschweigend auf Arial zurück. Die Seite selbst kommt über https://, aber irgendetwas darin fragt noch nach http://. Genau das ist Mixed Content, also gemischter Inhalt.

Warum eine einzige http://-Anfrage zählt

HTTPS schützt die ganze Seite nur, wenn jedes Byte über eine verschlüsselte Verbindung kommt. Ein einziges Skript, das über einfaches HTTP geladen wird, kann jeder auf dem Weg mitlesen und austauschen: ein offenes WLAN, ein kompromittierter Router, ein Provider, der Werbung einschleust. Ein ausgetauschtes Skript läuft mit vollem Zugriff auf die Seite: Es liest Formularfelder, schreibt Links um, stiehlt Sitzungsdaten. Die Verschlüsselung des HTML-Dokuments ist danach wertlos.

Browser teilen Mixed Content danach in zwei Gruppen ein, wie viel Schaden er anrichten kann.

• Aktiver (blockierbarer) Inhalt: Skripte, Stylesheets, iframes, Schriften, fetch- und XHR-Anfragen, Worker. Alles, was die Seite verändern oder aus ihr lesen kann. Moderne Browser blockieren ihn komplett — die Anfrage wird gar nicht erst gesendet, und in der Konsole erscheint ein Fehler.
• Passiver (upgradefähiger) Inhalt: Bilder, Audio und Video. Das Schlimmste, was ein Angreifer tun kann, ist ein Bild auszutauschen. Aktuelle Versionen von Chrome und Firefox laden solche Ressourcen gar nicht mehr über HTTP: Sie schreiben die URL automatisch auf https:// um, und ist die Ressource über HTTPS nicht erreichbar, wird sie einfach nicht geladen.

Ältere Browser und manche eingebetteten Web-Views zeigen passiven Mixed Content weiterhin unverändert an und markieren die Seite als nicht vollständig sicher — daher das fehlende oder durchgestrichene Schloss.

Formulare sind ein Sonderfall. Ein <form action="http://..."> auf einer HTTPS-Seite überträgt die Eingaben unverschlüsselt. Browser warnen vor dem Absenden eines solchen Formulars, und die Warnung wirkt so alarmierend, dass viele Nutzer abbrechen.

Woher er kommt

Fast jedes Mixed-Content-Problem ist ein Überbleibsel aus der Zeit vor der Umstellung.

• Fest eingetragene URLs in der CMS-Datenbank. Redakteure haben Bilder eingefügt, als die Website noch auf HTTP lief, also enthalten Beiträge, Widgets und Einstellungen weiterhin http://example.com/uploads/.... Die Website-Adresse im Admin-Bereich zu ändern, fasst bereits gespeicherte Inhalte nicht an.
• Alte Einbettungen. Videoplayer, Karten, Zähler und Chat-Widgets, die vor Jahren mit einer http://-URL eingefügt wurden. Manche dieser Anbieter liefern inzwischen über HTTPS aus, andere gibt es nicht mehr.
• CSS. background-image: url(http://...) in einem Stylesheet oder in einem style-Attribut, dazu @font-face, das auf einen Schrift-Host über HTTP zeigt.
• Responsive Bilder. Das src wurde korrigiert, aber srcset listet noch http://-Kandidaten, und auf einem Bildschirm mit hoher Pixeldichte wählt der Browser womöglich genau einen davon.
• Templates und JavaScript. Ein Theme, das absolute URLs mit fest verdrahtetem Schema zusammensetzt, oder ein Skript, das zur Laufzeit Ressourcen über http:// nachlädt.

So finden Sie ihn

DevTools. Seite öffnen, Konsole öffnen, neu laden. Jede Mixed-Content-Anfrage wird dort mit der genauen URL gemeldet, samt Hinweis, ob sie blockiert oder auf https umgestellt wurde. Im Network-Panel von Chrome beschränkt der Filter mixed-content:all die Liste auf genau diese Anfragen. Das funktioniert jeweils für eine Seite.

Statisches HTML. Ein schneller erster Durchgang über das Markup:

curl -s https://example.com/ | grep -Eo '(src|href|srcset|action)="http://[^"]+"'

URLs in CSS-Dateien und solche, die JavaScript hinzufügt, sieht er nicht, aber er findet die meisten CMS-Überbleibsel.

CSP-Reports. Um Mixed Content auf der ganzen Website mit echtem Traffic aufzuspüren, senden Sie eine Report-only-Policy, die nur HTTPS-Quellen erlaubt:

Content-Security-Policy-Report-Only: default-src https: data: blob: 'unsafe-inline' 'unsafe-eval'; report-uri /csp-report

Nichts wird blockiert, aber jeder Ladevorgang über http:// erzeugt einen Report mit Seite und URL. Beachten Sie, dass upgrade-insecure-requests in einer Report-only-Policy wirkungslos ist und die alte Direktive block-all-mixed-content als veraltet gilt — moderne Browser blockieren aktiven Inhalt ohnehin standardmäßig.

Auch ein SiteScan-Report prüft das: Er markiert jede gescannte Seite, die Ressourcen über http:// lädt, unter „Serve every asset over https://“.

So beheben Sie ihn

https:// oder relative URLs verwenden. Für eigene Ressourcen ist ein Pfad wie /uploads/photo.jpg die robusteste Lösung: Er übernimmt Schema und Domain der Seite. Bei Ressourcen von Drittanbietern wechseln Sie auf https:// und prüfen, ob der Anbieter sie tatsächlich so ausliefert. Falls nicht, ersetzen Sie die Ressource oder hosten Sie sie selbst.

Suchen und Ersetzen in der Datenbank — mit Vorsicht. Zuerst ein Backup. In WordPress nehmen Sie WP-CLI statt rohem SQL, weil es serialisierte PHP-Daten korrekt behandelt:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --dry-run

Sehen die Zahlen plausibel aus, führen Sie den Befehl ohne --dry-run erneut aus. Ein einfaches SQL-REPLACE verändert Stringlängen innerhalb serialisierter Werte und kann Widget- und Plugin-Einstellungen beschädigen.

upgrade-insecure-requests als Sicherheitsnetz setzen. Mit diesem Header schreibt der Browser jede http://-Subressource vor der Anfrage auf https:// um:

Content-Security-Policy: upgrade-insecure-requests

Das ist ein Sicherheitsnetz, keine Lösung: Hat ein Host kein HTTPS, schlägt die Anfrage einfach fehl, und die http://-URLs bleiben in Ihren Inhalten und Feeds stehen.

HSTS aktivieren, sobald die Website sauber ist. Strict-Transport-Security: max-age=31536000; includeSubDomains weist den Browser an, Ihre Domain nie wieder über HTTP anzusprechen. Beginnen Sie mit einem kurzen max-age und erhöhen Sie ihn, wenn Sie sicher sind, dass alle Subdomains über HTTPS funktionieren.

Checkliste

1. Die Konsole zeigt auf den wichtigsten Templates keine Mixed-Content-Warnungen.
2. Keine http://-URLs in src, href, srcset, action oder CSS-url().
3. Alte URLs in der Datenbank sind mit einem serialisierungssicheren Werkzeug ersetzt.
4. Einbettungen von Drittanbietern laden über HTTPS oder sind entfernt.
5. upgrade-insecure-requests ist als Sicherheitsnetz gesetzt.
6. HSTS ist erst aktiviert, nachdem alles oben Genannte sauber ist.