Warum gefährdet ein http://-Bild die Sicherheit der ganzen Seite, nicht nur dieses Bild?

Weil diese eine Anfrage unverschlüsselt und nicht authentifiziert ist, kann ein Angreifer im selben Netzwerk (öffentliches WLAN, ein kompromittierter Router) sie unterwegs abfangen oder verändern - und je nachdem, worum es sich handelt (besonders bei einem Skript), kann das den Rest der Seite kompromittieren, obwohl alles andere korrekt über HTTPS geladen wurde.

Blockiert der Browser Mixed Content automatisch, oder warnt er nur?

Das hängt vom Ressourcentyp ab. "Aktiver" Mixed Content - Skripte, Stylesheets, iframes - wird von modernen Browsern komplett blockiert. "Passiver" Mixed Content - Bilder, Video, Audio - wird meist trotzdem geladen, löst aber eine Warnung mit durchgestrichenem Schloss-Symbol in der Adressleiste aus, genau die Art von Vertrauenssignal, das Besucher zögern lässt.

Wie findet Scanverra Mixed Content - scannt es einfach mein HTML nach http://-Links?

Nein, es geht deutlich weiter. Scanverra lädt die Seite in einem echten Browser und erfasst die tatsächlichen Netzwerkanfragen, die die Seite stellt, und markiert dann jede Anfrage, die mit http:// beginnt, auf einer über https ausgelieferten Seite. Das erfasst auch Ressourcen, die dynamisch per JavaScript geladen werden, nicht nur im Markup hartkodierte.

Kann ich einfach upgrade-insecure-requests hinzufügen und mich nicht mehr um einzelne URLs kümmern?

Es hilft als Sicherheitsnetz - es weist den Browser an, http://-Anfragen automatisch vor dem Senden in https:// umzuschreiben -, funktioniert aber nur, wenn die Ressource an demselben Host tatsächlich über HTTPS verfügbar ist. Es ist eine gute Absicherung, kein Ersatz dafür, die hartkodierten URLs zu reparieren.

Mixed-Content-Warnungen beheben

Mixed Content entsteht, wenn eine über HTTPS ausgelieferte Seite auch nur eine Ressource - ein Skript, ein Bild, ein Stylesheet, ein iframe - über einfaches HTTP lädt. Diese eine unverschlüsselte Anfrage untergräbt das Sicherheitsversprechen des restlichen Seiteninhalts, und Browser reagieren, indem sie die Ressource blockieren, das Schloss-Symbol zerstören, oder beides.

Warum Mixed Content auftritt

Hartkodierte http://-URLs aus der Zeit vor einer HTTPS-Migration. Altes Markup, CMS-Inhalte oder eine Datenbank gespeicherter Asset-URLs, geschrieben, als die Website noch über einfaches HTTP lief, und nie aktualisiert.
Third-Party-Embeds und Widgets, die weiterhin über HTTP ausliefern. Ein Werbenetzwerk, ein Kommentar-Widget oder ein altes Analytics-Snippet, das seine eigene Auslieferung nie auf HTTPS umgestellt hat.
CDN- oder Asset-Host-URLs, die bei einer Protokoll-Migration übersehen wurden. Die Hauptdomain wechselte zu HTTPS, aber eine Subdomain oder ein Third-Party-Asset-Host für Bilder oder Schriften wurde nicht zeitgleich aktualisiert.
Nutzergenerierte Inhalte mit eingefügten HTTP-Links. Ein Nutzer reicht Inhalt ein (ein Forenpost, eine Produktbewertung, ein CMS-Feld) mit einer http://-Bild- oder -Embed-URL, die unverändert gerendert wird.

So findet man jede Instanz

Scanverra erkennt Mixed Content, indem es Ihre Seite in einem echten Browser lädt und deren tatsächliche Netzwerkaktivität erfasst - sowohl der Browser-Test als auch der Security-Scan markieren jede Anfrage, die mit http:// beginnt, während die Seite selbst über HTTPS ausgeliefert wird. Da dies auf echten erfassten Netzwerkanfragen beruht und nicht auf einem statischen Scan Ihres HTML-Quelltexts, erkennt es auch Ressourcen, die erst dynamisch per JavaScript nach dem Rendering geladen werden, nicht nur solche, die direkt im Markup hartkodiert sind.

So behebt man es

1. Hartkodierte http://-URLs durch https:// ersetzen

Vorher: eine hartkodierte http://-Bild-URLtypescript

1<img src="http://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

Nachher: über https ausgeliefert, oder protokollrelativ, falls der Host beides unterstützttypescript

1<img src="https://cdn.example.com/testimonial-1.jpg" alt="Customer headshot" />

2. upgrade-insecure-requests als Absicherung hinzufügen

Diese CSP-Direktive weist den Browser an, verbleibende http://-Anfragen automatisch vor dem Senden in https:// umzuschreiben, und fängt so übersehene URLs ab - funktioniert allerdings nur, wenn die Ressource an diesem Host tatsächlich über HTTPS erreichbar ist:

Jede vereinzelte http://-Anfrage automatisch auf https:// hochstufentypescript

1Content-Security-Policy: upgrade-insecure-requests

3. Third-Party-Embeds gezielt prüfen

Third-Party-Skripte und Widgets sind die häufigste Quelle für Mixed Content, die Sie nicht direkt kontrollieren - prüfen Sie in der Dokumentation jedes einzelnen, ob eine HTTPS-Embed-URL angeboten wird, und entfernen Sie jedes, das keine anbietet.

4. Protokoll in nutzergenerierten Inhalten bereinigen oder umschreiben

Können Nutzer Inhalte mit URLs einreichen, schreiben Sie http:// beim Rendern in https:// um (oder lehnen Sie die Einreichung ab), statt einfach das eingefügte Protokoll zu übernehmen.

Wie Scanverra dies erkennt

Sowohl Scanverras Browser-Test als auch dessen Security-Scan erfassen die echten Netzwerkanfragen Ihrer Seite in einem live laufenden Browser und markieren jede, die mit http:// beginnt, auf einer über HTTPS ausgelieferten Seite - eine echte Laufzeitprüfung gegen tatsächlichen Traffic, keine Textsuche im Quelltext.