Mixed Content tritt auf, wenn eine HTTPS-Seite Unterressourcen (Bilder, Skripte, Stylesheets, Schriftarten) über unverschlüsseltes HTTP lädt. Browser blockieren oder warnen davor, weil eine unsichere Ressource auf einer sicheren Seite die Sicherheit der gesamten Seite untergräbt.
Zwei Arten von Mixed Content
| Typ | Beispiele | Browserverhalten |
|---|---|---|
| Aktiv (gefährlich) | Skripte, iframes, XHR, CSS | Blockiert von allen Browsern |
| Passiv (Darstellung) | Bilder, Audio, Video | Angezeigt mit Warnung / degradiertem Schloss-Symbol |
Aktiver Mixed Content kann die Seite verändern (ein Man-in-the-Middle könnte bösartiges JavaScript einschleusen), daher blockieren Browser ihn vollständig. Passiver Mixed Content ist weniger gefährlich, verschlechtert aber dennoch die Sicherheitsanzeige.
So finden Sie Mixed Content
Browser-DevTools
- Öffnen Sie Ihre Website in Chrome/Firefox
- Öffnen Sie DevTools (F12) → Konsole-Tab
- Suchen Sie nach Fehlern wie:
Mixed Content: The page at 'https://example.com' was loaded over HTTPS, but requested an insecure resource 'http://example.com/image.jpg'.
Kommandozeilen-Scan
curl -s https://yourdomain.com | grep -oP 'http://[^"'"'"'> ]+' | sort -u
Häufige Ursachen und Lösungen
Fest codierte http://-URLs in HTML
<!-- Problem -->
<img src="http://example.com/logo.png">
<!-- Lösung: protokollrelativ oder HTTPS verwenden -->
<img src="https://example.com/logo.png">
<img src="//example.com/logo.png">
<img src="/logo.png">
Best Practice: Verwenden Sie relative Pfade (/images/logo.png) wo immer möglich.
Drittanbieter-Ressourcen noch auf HTTP
<!-- Problem -->
<script src="http://cdn.example.com/library.js"></script>
<!-- Lösung -->
<script src="https://cdn.example.com/library.js"></script>
Wenn der Drittanbieter kein HTTPS unterstützt, finden Sie einen alternativen Anbieter oder hosten Sie die Ressource selbst.
Datenbankinhalte mit fest codierten URLs
WordPress und andere CMS speichern absolute URLs in der Datenbank. Nach der Migration zu HTTPS:
-- WordPress: URLs in Beiträgen aktualisieren
UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com', 'https://example.com');
UPDATE wp_options SET option_value = REPLACE(option_value, 'http://example.com', 'https://example.com');
Oder verwenden Sie ein Plugin wie Better Search Replace.
CSS mit HTTP-Referenzen
/* Problem */
background-image: url('http://example.com/bg.jpg');
/* Lösung */
background-image: url('https://example.com/bg.jpg');
background-image: url('/images/bg.jpg');
Content Security Policy (CSP) — zukünftigen Mixed Content verhindern
Fügen Sie einen CSP-Header hinzu, der HTTP-Ressourcen blockiert:
Nginx:
add_header Content-Security-Policy "upgrade-insecure-requests" always;
Apache:
Header always set Content-Security-Policy "upgrade-insecure-requests"
upgrade-insecure-requests weist Browser an, http://-Anfragen automatisch auf https:// zu aktualisieren — ein Sicherheitsnetz, während Sie die Quell-URLs reparieren.
Systematische Lösung: Vollständige Website-Prüfung
Für eine gründliche Bereinigung prüfen Sie Ihre gesamte Website:
1. Nach HTTP-Referenzen crawlen
# Alle HTML-Dateien nach http://-URLs durchsuchen
find /var/www/html -name '*.html' -o -name '*.php' | xargs grep -l 'http://' 2>/dev/null
# CSS-Dateien durchsuchen
find /var/www/html -name '*.css' | xargs grep -l 'http://' 2>/dev/null
# JavaScript-Dateien durchsuchen
find /var/www/html -name '*.js' | xargs grep -l 'http://' 2>/dev/null
2. URLs nach Kategorie beheben
| Quelle | Lösungsmethode |
|---|---|
| Eigene Ressourcen | Auf relative Pfade ändern (/images/logo.png) |
| CDN-Ressourcen | Auf https://cdn.example.com/... aktualisieren |
| Drittanbieter-Skripte | URL aktualisieren oder HTTPS-Alternative finden |
| Inline-CSS | Suchen-Ersetzen http:// → https:// |
| Datenbankinhalte (WordPress) | wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' |
| Template-/Theme-Dateien | Quelldateien direkt bearbeiten |
3. Mit Browser-DevTools verifizieren
Öffnen Sie nach der Behebung jede Seite → DevTools (F12) → Konsole-Tab. Eine saubere Seite zeigt keine Mixed-Content-Warnungen. Das Schloss-Symbol sollte durchgehend sein (nicht gebrochen oder mit einem Warndreieck).
4. Zukünftigen Mixed Content verhindern
Fügen Sie dieses Meta-Tag in den <head> Ihres HTML als permanentes Sicherheitsnetz ein:
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
Oder setzen Sie es serverweit über die Nginx/Apache-Konfiguration (oben gezeigt).
Inhaltstypen, die häufig Mixed Content verursachen
| Inhaltstyp | Wo überprüfen | Beispiel |
|---|---|---|
| Bilder | <img src="http://..."> | Hochgeladene Bilder, Avatare, Logos |
| Skripte | <script src="http://..."> | Analytics, Chat-Widgets, Werbeskripte |
| Stylesheets | <link href="http://..."> | Externe Schriften, CSS-Frameworks |
| Schriftarten | @font-face { src: url("http://...") } | Google Fonts (normalerweise kein Problem), benutzerdefinierte Schriften |
| iframes | <iframe src="http://..."> | Eingebettete Videos, Karten, Widgets |
| XHR/Fetch | fetch("http://...") | API-Aufrufe in JavaScript |
| Hintergrundbilder | background-image: url("http://...") | CSS-Hintergründe |
Häufig gestellte Fragen
Beeinflusst Mixed Content mein SEO?
Nicht direkt. Google crawlt basierend auf dem URL-Protokoll der Seite, nicht auf Unterressourcen. Wenn Mixed Content jedoch Browser-Warnungen auslöst oder sichtbare Inhalte blockiert, verschlechtert sich die Benutzererfahrung — was Rankings indirekt durch höhere Absprungraten beeinträchtigen kann.
Kann ich einfach upgrade-insecure-requests verwenden und die URLs nicht reparieren?
Es funktioniert als Übergangslösung, aber die Quell-URLs zu reparieren ist besser. Der CSP-Header hängt von der Browser-Unterstützung ab (alle modernen Browser unterstützen ihn, aber einige ältere Clients nicht) und fügt jeder Antwort einen zusätzlichen Header hinzu.
Meine Website hat Hunderte von fest codierten HTTP-URLs. Was ist die schnellste Lösung?
Fügen Sie sofort den CSP-Header upgrade-insecure-requests hinzu (eine Zeile Serverkonfiguration). Führen Sie dann ein globales Suchen-und-Ersetzen in Ihrem Codebase und Ihrer Datenbank durch. Verwenden Sie grep -r 'http://' src/, um fest codierte URLs im Code zu finden.