Chrome 154 fragt vor dem Laden von HTTP: Was sich für Dev, Staging und Testautomatisierung ändert

Wenn Sie jemals einen Staging-Link geteilt haben, der mit http:// beginnt, hat Chrome dazu eine Meinung. Chrome 154 hat „Always Use Secure Connections“ standardmäßig aktiviert. Chrome versucht zuerst HTTPS und bittet den Benutzer um Erlaubnis vor dem ersten Besuch einer öffentlichen Website, die nicht über HTTPS erreichbar ist.

Für den durchschnittlichen Besucher einer modernen Website ändert sich nichts. Für Entwickler ist die Geschichte jedoch anders. Der Schmerz trifft nicht auf localhost, der ausgenommen ist. Er trifft auf die ruhigeren Ecken eines realen Workflows: Staging-Server mit öffentlichen Hostnamen, Preview-Umgebungen, zu denen niemand ein Zertifikat eingerichtet hat, alte Weiterleitungsketten und CI-Jobs, bei denen niemand da ist, der auf „Weiter“ klicken kann.

Dieser Leitfaden deckt ab, was ausgeliefert wurde, wie die Warnung funktioniert, wo sie Entwickler- und QA-Workflows unterbricht, das genaue Flag für die Testautomatisierung und wie man das zugrunde liegende Problem behebt, anstatt es zu kaschieren.

TL;DR

• Chrome 154 erreichte den stabilen Kanal am 22. September 2026, mit der public-sites-Variante von „Always Use Secure Connections“ standardmäßig aktiviert. Googles eigener Launch-Beitrag folgte am 21. Oktober 2026.
• Chrome versucht zuerst HTTPS. Wenn HTTPS fehlschlägt, aber HTTP möglicherweise funktioniert, fragt es vor dem Laden der Seite über HTTP.
• localhost, lokale IP-Adressen, Hostnamen mit nur einem Label und nicht eindeutige Namen wie staging.local lösen die Warnung nicht aus.
• Ein öffentlicher Hostname, der über HTTP bedient wird, kann es auslösen. Für einen Menschen funktioniert das Durchklicken weiterhin, also ist es eher eine Hürde als eine Wand. Für unbeaufsichtigte Automatisierung kann es eine Barriere darstellen.
• Für die Testautomatisierung ist der dokumentierte Ausweg von Chromium der Befehlszeilen-Schalter --unsafely-treat-insecure-origin-as-secure.
• Die dauerhafte Lösung besteht darin, HTTPS auf jedem öffentlichen Hostnamen zu verwenden, einschließlich jedes Weiterleitungsschritts.

Was Chrome 154 tatsächlich geändert hat

Das “Always Use Secure Connections”-Flag ist nicht neu. Chrome führte es 2022 als Opt-in-Funktion ein. Google fügte später eine Variante hinzu, die auf öffentliche Sites beschränkt ist, weil HTTP zu privaten Sites weniger Risiko birgt. Was sich in Chrome 154 geändert hat, ist der Standard.

Hier ist die Einführung, wie Google sie beschrieben hat:

Wann	Was geschah
2022	„Always Use Secure Connections“ wird als Opt-in-Einstellung gestartet
2024	Eine Variante, die nur öffentliche Sites betrifft, wird eingeführt
Chrome 141	Google experimentiert damit, die public-sites-Variante für einen kleinen Prozentsatz von Nutzern zu aktivieren
28. Oktober 2025	Das Chrome-Sicherheitsteam kündigt den Plan an, es standardmäßig zu aktivieren
Chrome 147 (April 2026)	Standardmäßig aktiviert für Nutzer, die Enhanced Safe Browsing verwenden, eine Gruppe, die von Googles Ankündigung auf über eine Milliarde Menschen geschätzt wird
Chrome 154 (22. September 2026)	Standardmäßig aktiviert für alle, gemäß den Chrome 154 Release-Notizen
21. Oktober 2026	Google veröffentlicht „Chrome Now Warns Before Insecure HTTP Connections“, und bestätigt die Ausrollung für alle Benutzer

Ein Detail ist es wert, zu korrigieren, falls Sie frühere Berichterstattung gelesen haben. Die ursprüngliche Ankündigung sagte, die Änderung würde im Oktober 2026 eintreffen. Chrome 154 erreichte tatsächlich den stabilen Stand am 22. September 2026, weil Chrome ab Chrome 153 am 8. September auf einen zweiwöchigen Release-Zyklus umgestellt hat. Die Chrome 154 Release Notes listen „Ask before HTTP on by default“ und sagen, Administratoren können es mit der Enterprise-Richtlinie HttpsOnlyMode steuern. Wie bei jeder stabilen Version erfolgt die Ausrollung auf jedem Computer schrittweise, sodass Sie möglicherweise noch auf einige ältere Builds im Einsatz stoßen.

Warum hat Google das getan? Laut dem Chrome Security Team stieg der Anteil der Seitenaufrufe über HTTPS von rund 30 % auf 45 % im Jahr 2015 auf den Bereich 95–99 % um 2020, und ist seither weitgehend stabil geblieben. Der verbleibende Anteil ist aus zwei Gründen bedeutsam:

• Ein Angreifer benötigt nur eine unsichere Navigation, um Fuß zu fassen, zum Beispiel indem er die Navigation kapert und vom Angreifer kontrollierte Ressourcen lädt.
• Viele Klartext-HTTP-Verbindungen bleiben für Benutzer unsichtbar, da die HTTP-Seite sofort zu HTTPS weiterleitet. Das alte „Not Secure“-Badge kommt nie zur Anzeige.

Im Chrome-141-Experiment erreichten Warnungen deutlich unter 3 Prozent der Navigationsvorgänge. Der mittlere Benutzer sah weniger als eine Warnung pro Woche, und der 95.-Perzentil-Benutzer sah weniger als drei. Googles Oktober-2026-Beitrag ergänzt Frührollout-Daten: Fast 95 Prozent der Desktop-Chrome-Nutzer sehen in einer Woche keine HTTP-Warnung, und weniger als 1 Prozent sehen drei oder mehr. Die Warnraten auf Mobilgeräten liegen noch niedriger. Google merkt auch an, dass Chrome der erste Browser ist, der diese Änderung standardmäßig aktiviert.

Wie die Warnung funktioniert

Dieses Verständnis der Funktionsweise erspart Ihnen das Hinterherjagen von Phantomproblemen. Das Chromium-eigene Einführungsleitfaden sagt Folgendes.

Auslöser. Die Warnung erscheint, wenn Chrome keine Verbindung über HTTPS herstellen konnte, aber glaubt, dass eine Verbindung über HTTP möglich sein könnte. Chrome fordert dann vor dem Laden der Seite eine Bestätigung an.

Speicher. Chrome merkt sich die Entscheidung des Nutzers 15 Tage lang, und die Ausnahme wird erneuert, wenn der Nutzer die Seite erneut besucht. Wenn Sie häufig eine HTTP-Seite verwenden, sehen Sie die Warnung möglicherweise nur einmal. Googles Launch-Beitrag beschreibt dies als keine neue Warnung, bis die Seite mindestens zwei Wochen lang nicht besucht wurde.

Explizites HTTPS fällt nie auf HTTP zurück. Wenn eine Verbindung https:// festlegt ist und die Verbindung fehlschlägt, erhalten Sie eine normale Netzwerkfehlermeldung und Chrome versucht kein HTTP.

HSTS gewinnt. Wenn eine Website HTTP Strict Transport Security (HSTS) konfiguriert hat, fällt Chrome nicht auf HTTP zurück. HSTS hat Vorrang vor automatischen Upgrades und der neuen Warnung.

Weiterleitungen zählen. Wenn ein Schritt in einer Weiterleitungskette kein HTTPS unterstützt, zeigt Chrome die Warnung an, selbst wenn das endgültige Ziel eine sichere HTTPS-Seite ist. Ein Beispiel aus der Anleitung: https://www.example.com ist in Ordnung, aber http://example.com leitet zu http://www.example.com weiter und die Spitze hat kein HTTPS. Besucher, die example.com tippen, bekommen die Warnung. Mehrere unsichere Zwischenstationen können mehrere Warnungen in einer einzigen Navigation bedeuten.

Zertifikatfehler bleiben unverändert. Ein abgelaufenes Zertifikat oder ein falsch konfigurierter Server erzeugt weiterhin die bestehenden Zertifikatwarnungen, und es wird kein zusätzlicher Warnungstyp hinzugefügt.

Bestehende Einstellungen werden respektiert. Wenn Sie die Einstellung vorher in irgendeiner Richtung gesetzt hatten, hält Chrome daran fest.

Was ist ausgenommen, und warum Entwickler das wichtig finden

Chrome teilt die Welt in öffentliche und private Websites, und die Warnung gilt nur für öffentliche Websites. Private Websites sind aus zwei Gründen ausgeschlossen:

• Beispiele sind lokale IP-Adressen wie 192.168.0.1, Hostnamen mit nur einem Label wie intranet/, und interne Shortlinks.
• Es gibt keinen praktikablen Weg für eine Zertifizierungsstelle, ein öffentlich vertrauenswürdiges Zertifikat für einen nicht eindeutigen Namen auszustellen, und Angreifer müssen in der Regel im selben Netzwerk sein, um sie auszunutzen.

Für die lokale Entwicklung fasst der Umsetzungsleitfaden Folgendes zusammen:

• http://localhost gilt als sicher und zeigt keine Warnung an.
• Lokale Namen wie staging.local, nicht eindeutige Hostnamen, lokale IP-Adressen und Hostnamen mit nur einem Label zeigen ebenfalls keine Warnung.
• Ein Entwicklungsserver auf einem öffentlichen Hostnamen ohne HTTPS kann die Warnung anzeigen. Durch das Klicken geht die Entwicklung wie heute weiter.

Unternehmen können die andere Richtung einschlagen. Die Richtlinie HttpsOnlyMode kann so eingestellt werden, dass der neue Standard festgelegt wird, z. B. auf force_balanced_enabled, oder force_enabled, um Benutzer in den Strict Mode zu versetzen, in dem Warnungen auch für private Websites erscheinen.

Wo ein Tunnel passt

Es gibt eine Situation, die die obigen Schritte nicht sauber lösen. Sie haben einen Entwicklungsserver auf Ihrem Rechner laufen, und ein Kollege, Kunde oder Webhook-Absender muss von außerhalb darauf zugreifen. Selbst gehostete HTTPS für eine temporäre Umgebung ist oft aufwendiger als die Aufgabe.

Hier kommt ein HTTPS-Tunnel ins Spiel. InstaTunnel bedient Tunnels standardmäßig über HTTPS, sodass die URL, die Sie teilen, von der ersten Klick an eine https://-Adresse ist. Ein Prüfer, der sie öffnet, begegnet keiner HTTP-Warnung, und Sie müssen kein Zertifikat für einen Hostnamen bereitstellen, den Sie morgen wieder löschen. Eine stabile benutzerdefinierte Unter-domain sorgt außerdem dafür, dass der Link, den Sie in ein Ticket einfügen, funktioniert, statt bei jeder Sitzung eine neue URL zu verteilen.

Zwei ehrliche Hinweise gelten für jeden Tunnel, nicht nur unseren:

• Ihre Anwendung spricht lokal weiterhin HTTP. Der Tunnel beendet HTTPS am Edge und leitet an Ihren Entwicklungsserver weiter. Wenn Ihr Framework absolute URLs erzeugt oder Weiterleitungen basierend auf dem Protokoll der Anforderung erzwingt, stellen Sie sicher, dass es den weitergeleiteten Protokoll-Header korrekt vertraut, sonst sehen Sie Weiterleitungsschleifen oder Mixed-Content-Probleme. Viele Entwicklungsserver lehnen standardmäßig auch unbekannte Host-Header ab, daher muss der Tunnel-Hostname möglicherweise zu einer allowed-hosts-Einstellung hinzugefügt werden.
• Ein Tunnel ist kein Ersatz für eine echte Staging-Umgebung. Wenn eine geteilte Umgebung Monate lang bestehen soll, geben Sie ihr einen realen Hostnamen und ein automatisiertes Zertifikat. Verwenden Sie den Tunnel für die kurzlebigen, „share-this-right-now“-Fälle, in denen er gut geeignet ist.

Eine scoping-Hinweis: Dies ist ein anderer Mechanismus als CrHome’s Local Network Access-Eingabeaufforderungen, die sich darauf beziehen, dass eine öffentliche Seite in Ihr lokales Netzwerk greift. Chrome 154 erweitert auch diesen Bereich. Es fügt dem WebSocket-Konstruktor eine targetAddressSpace-Option hinzu, die es erlaubt, eine Verbindung zu einem öffentlichen Hostnamen so zu behandeln, als ginge sie zu einem lokalen oder Loopback-Ziel. Die Chrome 154 Release Notes beschreiben es als einen Weg, Mixed-Content-Beschränkungen zu umgehen, wenn man mit lokalen Servern ohne HTTPS spricht, vorausgesetzt der Benutzer erteilt die Berechtigung für das lokale Netzwerk. Ask-before-HTTP dagegen bezieht sich darauf, zu einer öffentlichen Seite zu navigieren, die kein HTTPS hat.

Häufig gestellte Fragen

Blockiert Chrome 154 HTTP-Sites?
Nein. Es fragt vor dem ersten Besuch einer öffentlichen HTTP-Site um Erlaubnis, und die Warnung ist umgehbar. Chrome merkt sich auch die Wahl für 15 Tage und erneuert sie bei jedem Besuch.

Wird http://localhost die Warnung angezeigt?
Nein. Chrome behandelt es als sicher. Lokale IP-Adressen, Hostnamen mit nur einem Label und nicht eindeutige Namen wie staging.local sind ebenfalls ausgenommen.

Kann ich es für mich selbst deaktivieren?
Ja. Deaktivieren Sie “Always Use Secure Connections” in chrome://settings/security. Wenn Sie es vor Chrome 154 in irgendeiner Weise eingestellt haben, behält Chrome Ihre Wahl bei.

Wie stoppe ich die Warnung in Selenium oder Playwright?
Verwenden Sie --unsafely-treat-insecure-origin-as-secure mit den konkreten Ursprüngen oder Wildcard-Hosts, die Ihre Tests verwenden.

Was ist mit Firefox, Safari und Edge?
Laut dem Chromium-Leitfaden verschieben alle drei Browser HTTP-Navigationen bereits zu HTTPS und bieten optionale Modi, die vor dem Zurückfallen auf HTTP warnen. Der Unterschied ist, dass Chrome die Warnung jetzt standardmäßig aktiviert.

Fazit

Chrome 154 hat das Web nicht kaputt gemacht, und bei den meisten Websites hat sich sichtbar nichts geändert. Aber es hat eine klare Grenze gezogen: Öffentlich bedeutet HTTPS. Entwickler behalten eine Freifahrt auf localhost und privaten Namen, während Staging-Server, Vorschau-Umgebungen und Testautomatisierung auf öffentlichen Hostnamen nun entweder ein gültiges Zertifikat benötigen oder eine gezielte, enge Ausnahme. Verbringen Sie einen Nachmittag damit, die Einstellung zu aktivieren, Ihre Umgebungen zu überprüfen und die Hosts zu reparieren, die Warnungen auslösen. Es ist günstiger, als jedem Kunden, der einen Demo-Link öffnet, die Warnung zu erklären.

Quellen

• Standardmäßig HTTPS, Chrome Security Team (28. Okt 2025)
• Chrome Now Warns Before Insecure HTTP Connections, Chrome Secure Web and Networking Team (21. Okt 2026)
• Anpassen Ihrer Website an Chrome’s „Ask-before-HTTP“ Warnung, Chromium Docs
• Chrome 154 Release Notes, Chrome for Developers
• Get features faster with Chrome’s two-week release cycle, Chrome for Developers Blog (Mar 3, 2026)
• Fresher features, faster fixes: The two-week release cycle is here, Chrome for Developers Blog (Sep 8, 2026)
• Google Chrome starts two-week release cycle with version 153, 9to5Google
• Chrome to Turn HTTPS on by Default for Public Sites, SecurityWeek
• Chrome Will Default to HTTPS for All Public Sites Starting October 2026, CyberInsider