Veröffentlicht am 16. April 2026
Webanwendungen werden immer komplexer, insbesondere mit dem Aufkommen von integrierter generativer KI. Daher hat der Schutz von Nutzerdaten höchste Priorität. Aus diesem Grund kündigen wir den Ursprungstest für Zulassungslisten für Verbindungen an, einen neuen Sicherheitsmechanismus, der eine Netzwerk-Sandbox für Dokumente und Worker erstellt.
Hintergrund
In einem modernen Web-Ökosystem werden ständig vertrauliche Daten zwischen Clients und Servern übertragen. Diese Mobilität in Kombination mit einer komplexen Lieferkette von Drittanbieter-Skripts und dem Aufkommen von dynamisch generiertem Code aus generativer KI erhöht das Risiko der Datenexfiltration erheblich.
Schädliche Skripts, Schwachstellen in gebündelten Bibliotheken oder unbeabsichtigtes Verhalten in von generativer KI generiertem Code können Überprüfungen auf Anwendungsebene umgehen, um vertrauliche Informationen an nicht autorisierte Endpunkte zu senden. Die Content Security Policy (CSP) ist zwar ein leistungsstarkes Tool, um zu steuern, was eine Seite laden und ausführen kann, aber die Verwaltung ihrer Komplexität, um einzuschränken, wohin eine Seite kommuniziert , kann schwierig sein. Dies führt oft zu umfassenden Richtlinien, die Raum für nicht autorisierte Netzwerkaktivitäten lassen.
Sandbox für Zulassungslisten für Verbindungen
Zulassungslisten für Verbindungen bieten eine direkte Methode, um diese Risiken zu minimieren, indem der Browser zum Gatekeeper aller Netzwerkverbindungen wird, die von Ihrer Seite ausgehen. Durch Einbeziehung des Connection-Allowlist HTTP-Antwortheaders gibt eine Website die genauen URL-Muster an, die für die gesamte Netzwerkkommunikation zulässig sind, die von ihrem Kontext aus initiiert wird, z. B. ein Dokument oder ein Web-Worker.
Diese Funktion erzwingt eine Firewall auf Framework-Ebene, die standardmäßig alle Verbindungen ablehnt. Bevor eine Verbindung hergestellt wird, z. B. ein Abruf einer Unterressource, eine Navigationsumleitung oder eine WebSocket-Verbindung, überprüft der Browser das Ziel anhand der Zulassungsliste. Wenn der Endpunkt nicht übereinstimmt, blockiert der Browser die Verbindung auf Netzwerkebene. Der Browser behält die Netzwerkgrenzen bei, auch wenn schädlicher Code versucht, die Logik auf Anwendungsebene zu umgehen.
Funktionsweise von Zulassungslisten für Verbindungen
Zulassungslisten für Verbindungen bieten eine direkte Methode, um diese Risiken zu minimieren, indem der Browser zum Gatekeeper aller Netzwerkverbindungen wird, die von Ihrer Seite ausgehen. Durch Einbeziehung des Connection-Allowlist HTTP-Antwortheaders gibt eine Website die genauen URL-Muster an, die für die gesamte Netzwerkkommunikation zulässig sind, die von ihrem Kontext aus initiiert wird. Für den Ursprungstest wird dies nur für Dokumentkontexte unterstützt.
Bevor eine Verbindung hergestellt wird, z. B. ein Abruf einer Unterressource, eine Navigationsumleitung oder eine WebSocket-Verbindung, überprüft der Browser das Ziel anhand der Zulassungsliste. Wenn der Endpunkt nicht übereinstimmt, blockiert der Browser die Verbindung auf Netzwerkebene. So wird sichergestellt, dass die Netzwerkgrenzen eingehalten werden, auch wenn schädlicher Code versucht, die Logik auf Anwendungsebene zu umgehen.
Token response-origin verwenden
Sie können das Token response-origin verwenden, mit dem der Ursprung, von dem die Antwort bereitgestellt wird, dynamisch zur Zulassungsliste hinzugefügt wird:
Connection-Allowlist: ("https://api.example.com/*" response-origin)
In diesem Beispiel kann die Seite eine Verbindung zu jedem Pfad auf ihrem Ursprung und dem angegebenen API-Endpunkt herstellen.
Verstöße melden
Wenn Sie potenzielle Probleme beobachten möchten, ohne die Funktionalität Ihrer Website zu beeinträchtigen, können Sie den Header Connection-Allowlist-Report-Only verwenden. Bei dieser Variante wird die
Richtlinie geparst und Verstöße werden über die Reporting
API an einen angegebenen Endpunkt gesendet.
Connection-Allowlist: ("https://trusted.com/*"); report-to=security-endpoint
Gängige Anwendungsfälle
Zulassungslisten für Verbindungen sind in Umgebungen mit hohen Sicherheitsanforderungen oder dynamischen Umgebungen nützlich:
- Generative KI und nicht vertrauenswürdiger Code:Wenn Nutzer auf Ihrer Website generierten oder nicht vertrauenswürdigen Code ausführen können, z. B. in Sheets Canvas oder Entwicklungssandboxes, können Zulassungslisten für Verbindungen verhindern, dass der Code Daten an externe Domains überträgt.
- Aufsicht durch Dritte:Sie können dafür sorgen, dass Daten auch dann nicht an nicht autorisierte Server gesendet werden können, wenn ein Drittanbieter-Skript kompromittiert wurde.
- Architektonische Sicherheitsmaßnahmen:Erzwingen Sie eine strikte Netzwerkgrenze für vertrauliche Teile Ihrer Anwendung und sorgen Sie dafür, dass die Kommunikation nur mit genehmigten Back-Ends erfolgt.
Unterschiede zur Content Security Policy
Zulassungslisten für Verbindungen und CSP haben zwar ähnliche Ziele, ergänzen sich aber:
- Fokus auf Netzwerkebene:Zulassungslisten für Verbindungen konzentrieren sich auf das Ziel von Netzwerkverbindungen und nicht darauf, wie eine Ressource geladen oder ausgeführt wird.
- Umfassende Abdeckung:Sie decken Navigationen, Umleitungen und verschiedene Webplattform-APIs einheitlich ab, z. B. Fetch, WebRTC, WebTransport, DNS-Vorabruf und Preload.
- Vereinfachte Syntax:Zulassungslisten für Verbindungen konzentrieren sich auf eine einzige Aufgabe, was die Konfiguration und Sicherheitsprüfung vereinfacht.
Mit Zulassungslisten für Verbindungen experimentieren
Die Funktion „Zulassungslisten für Verbindungen“ ist für lokale Tests verfügbar. Der Ursprungstest soll von Chrome 148 bis Chrome 151 laufen. Im Laufe des Ursprungstests werden weitere Funktionen hinzugefügt. Zu Beginn dieses Tests ist die Berichtsfunktion auf Dokumentkontexte beschränkt. Dedicated, Shared und Service Worker werden nicht unterstützt. Weitere Informationen zu den unterstützten Funktionen finden Sie im Abschnitt Für den Ursprungstest registrieren.
Lokal testen
- Aktivieren Sie das Flag: Öffnen Sie Chrome und rufen Sie
chrome://flags/#connection-allowlistauf. Setzen Sie das Flag auf Aktiviert. - Header bereitstellen: Konfigurieren Sie Ihren lokalen Entwicklungsserver so, dass der HTTP-Antwortheader
Connection-Allowlistgesendet wird. Beispiel:Connection-Allowlist: ("https://api.example.com/*" response-origin). - Mit den Entwicklertools überprüfen: Öffnen Sie die Chrome-Entwicklertools und führen Sie Aktionen aus, die Netzwerkanfragen auslösen.
- Bereich Netzwerk: Suchen Sie nach Anfragen, die mit „blockiert:other“ gekennzeichnet sind oder einen Verbindungsfehler aufweisen.
- Tab Probleme: Hier finden Sie detaillierte Berichte, wenn beim Parsen des Headers Fehler aufgetreten sind.
Für den Ursprungstest registrieren
Lokale Tests sind zwar ideal für die Entwicklung, aber Sie müssen sich für den Ursprungstest registrieren, um Zulassungslisten für Verbindungen für Ihre Nutzer in der Produktion zu aktivieren.
- Rufen Sie das Dashboard für Chrome-Ursprungstests auf.
- Suchen Sie den Ursprungstest Zulassungslisten für Verbindungen und klicken Sie auf Registrieren.
- Fügen Sie das generierte Token den Seiten oder Headern Ihrer Website hinzu, wie im Leitfaden Erste Schritte mit Ursprungstests beschrieben.
Der Ursprungstest soll von Chrome 148 bis Chrome 151 laufen. Im Laufe des Ursprungstests werden weitere Funktionen hinzugefügt. Daher empfehlen wir dringend, Ihre vorhandenen Websicherheitsmechanismen weiterhin zu verwenden, während Sie Zulassungslisten für Verbindungen testen. In der Absichtserklärung zum Experiment finden Sie weitere Informationen zu den Netzwerkendpunkten, die von der Implementierung von Zulassungslisten für Verbindungen abgedeckt werden.
Feedback geben
Geben Sie Feedback zum Design und zur Nützlichkeit der Funktion. Wenn Probleme auftreten oder Sie Verbesserungsvorschläge haben, wenden Sie sich an das Team:
- GitHub: Erstellen Sie ein Problem oder kommentieren Sie ein vorhandenes im
WICG/connection-allowlistsRepository. - Chromium-Problemtracker: Erstellen Sie ein Problem im Chromium-Problem tracker.