Unverschlüsselte Inhalte auf HTTPS-Seiten

Was wir prüfen

Wird die Startseite über HTTPS ausgeliefert, suchen wir im gelieferten und im gerenderten HTML nach Adressen, die mit http:// beginnen, und ergänzen das um die Anfragen, die der Browser beim Laden tatsächlich über HTTP geschickt hat.

• Formulare, deren Ziel eine http://-Adresse ist: kritisch. Die Eingaben der Besucher reisen unverschlüsselt.
• Skripte, Stylesheets, Frames und Objekte über http://: kritisch. Browser blockieren sie, Funktionen und Layout fallen aus.
• Bilder, Videos und Audio über http://: Warnung. Browser versuchen eine Umstellung auf HTTPS und zeigen die Datei sonst nicht.

Relative Pfade (/bilder/logo.png) und protokollrelative Adressen (//cdn.example.ch/...) sind in Ordnung.

Warum das wichtig ist

Eine verschlüsselte Seite verspricht Besuchern, dass niemand unterwegs mitliest oder Inhalte verändert. Jede über HTTP nachgeladene Datei bricht dieses Versprechen für genau diese Datei. Bei einem Skript heisst das: Wer im selben Netz sitzt, etwa in einem öffentlichen WLAN, könnte es durch ein eigenes ersetzen und damit die ganze Seite kontrollieren.

Browser reagieren deshalb hart. Skripte und Stylesheets über HTTP werden still blockiert; die Seite sieht dann kaputt aus, ohne dass jemand eine Meldung bekommt. Das Schloss-Symbol in der Adressleiste verschwindet, und bei Formularen warnt der Browser vor dem Absenden.

Für Suchmaschinen zählt eine Seite mit gemischten Inhalten nicht als vollständig sicher.

So behebst Du es

Adressen im Inhalt

Such in Texten, Bildern und Vorlagen nach http:// und ersetze es durch https:// oder durch relative Pfade. Für WordPress gibt es Plugins wie «Better Search Replace», die das in der ganzen Datenbank erledigen. Prüfe dabei auch die Einstellung der Site-Adresse (WordPress: «Einstellungen › Allgemein»).

Eingebundene Dienste

Alte Einbettungen von Karten, Videos, Schriften oder Zählern verwenden manchmal noch http://. Hol den aktuellen Einbettungscode beim Anbieter, der ist heute immer https://.

Formulare

Das Ziel eines Formulars (action) muss eine https://-Adresse sein. Bei Formular-Diensten prüfst Du die Einstellungen des Dienstes.

Absicherung für die Zukunft

Mit dem Header Content-Security-Policy: upgrade-insecure-requests weist Du Browser an, alle http://-Adressen der Seite automatisch über HTTPS anzufordern. Das fängt vergessene Links ab, ersetzt das Korrigieren aber nicht.

So prüfst Du es selbst

Öffne die Seite in Chrome und klick auf das Symbol links in der Adressleiste. Steht dort «Nicht sicher» oder ein Hinweis auf unsichere Inhalte, ist etwas gemischt. In den Entwicklertools (F12) unter «Konsole» stehen die betroffenen Dateien mit dem Vermerk «Mixed Content».

Häufige Fragen

Die Seite hat ein gültiges Zertifikat. Reicht das nicht?

Das Zertifikat verschlüsselt die Seite selbst. Jede eingebundene Datei hat aber ihre eigene Adresse. Beginnt sie mit http://, wird sie unverschlüsselt angefordert, egal wie gut die Seite geschützt ist.

Browser stellen Bilder doch automatisch auf HTTPS um?

Chrome, Firefox und Safari versuchen das bei Bildern und Medien. Gelingt es nicht, zeigen sie die Datei gar nicht an. Skripte und Stylesheets blockieren sie ohne Versuch. Verlass Dich nicht darauf, sondern korrigiere die Adressen.

Woher kommen diese http://-Adressen?

Meist aus der Zeit vor der Umstellung auf HTTPS: alte Bildlinks in Texten, eine fest eingetragene Site-URL im CMS oder ein Theme, das Dateien mit vollständiger Adresse einbindet.