Diese Seite wurde von der Cloud Translation API übersetzt.

Sichere Pop-up-Interaktionen mit Einschränkungseigenschaften

Hol dir ursprungsübergreifende Isolation und Schutz vor websiteübergreifenden Datenlecks, wenn du mit Pop-ups interagierst.

Arthur Hemery

Maud Nalpas

Für die Cross-Origin Opener Policy (COOP) ist ein neuer Wert verfügbar: restrict-properties. Sie bietet Sicherheitsvorteile und erleichtert die Implementierung der ursprungsübergreifenden Isolierung. Gleichzeitig ermöglicht sie Ihrer Website die Interaktion mit Pop-ups von Drittanbietern für Zahlungen, Authentifizierung oder andere Anwendungsfälle.

Wenn du restrict-properties ausprobieren möchtest, nimm am Ursprungstest ab Chrome 116 teil.

Vorteile von `restrict-properties`

Für restrict-properties gibt es zwei Hauptanwendungsfälle:

Websiteübergreifende Datenlecks werden ohne Fehler verhindert.
Deine Website ursprungsübergreifend isoliert gestalten.

Websiteübergreifende Datenlecks vermeiden

Standardmäßig kann jede Website Ihre Anwendung in einem Pop-up öffnen und einen Verweis darauf abrufen.

Betrügerische Websites können dies zu ihrem Vorteil nutzen, um Angriffe wie websiteübergreifende Datenlecks durchzuführen. Sie können den Cross-Origin-Opener-Policy-Header (COOP) verwenden, um dieses Risiko zu minimieren.

Bisher waren deine Optionen für Cross-Origin-Opener-Policy eingeschränkt. Sie haben folgende Möglichkeiten:

Legen Sie same-origin, fest, um alle ursprungsübergreifenden Interaktionen mit Pop-ups zu blockieren.
Legen Sie same-origin-allow-popups fest. Dadurch werden alle ursprungsübergreifenden Interaktionen blockiert, bei denen Ihre Website in einem Pop-up-Fenster geöffnet wird.
Legen Sie unsafe-none fest, um alle ursprungsübergreifenden Interaktionen mit Pop-ups zuzulassen.

Dadurch war es für Websites unmöglich, die in einem Pop-up geöffnet werden mussten, um COOP zu erzwingen. Dadurch sind wichtige Anwendungsfälle wie die Einmalanmeldung (SSO) und Zahlungen nicht vor websiteübergreifenden Datenlecks geschützt.

Cross-Origin-Opener-Policy: restrict-properties löst dieses Problem.

Mit restrict-properties sind keine Eigenschaften verfügbar, die für die Frame-Zählung und andere Cross-Site-Leck-Angriffe verwendet werden können. Die grundlegende Kommunikation zwischen Fenstern über postMessage und closed ist jedoch erlaubt.

So wird die Sicherheit einer Website verbessert und gleichzeitig wichtige Anwendungsfälle beibehalten. Beispiel:

Wenn du einen Dienst in einem Pop-up anbietest, schützt du dich mit Cross-Origin-Opener-Policy: restrict-properties vor einer Reihe von websiteübergreifenden Leak-Angriffen. Sie können weiterhin alle Seiten öffnen, die Sie zuvor geöffnet haben konnten.
Wenn Sie auf ein ursprungsübergreifendes Pop-up zugreifen müssen, wird Ihre Website durch das Festlegen von Cross-Origin-Opener-Policy: restrict-properties vor der iFrame-Zählung geschützt. Sie werden die gleichen Pop-ups öffnen wie heute.
Wenn sowohl der Anfang als auch der Server den Header festlegen und die Seiten ursprungsübergreifend sind, verhält es sich ähnlich wie bei einer Seite, bei der der Header festgelegt wurde. Wenn sie denselben Ursprung haben, wird vollständiger Zugriff gewährt.

Website ursprungsübergreifend isolieren

Warum wir die ursprungsübergreifende Isolierung benötigen

Einige Web-APIs erhöhen das Risiko von Seitenkanalangriffen wie Spectre. Um dieses Risiko zu verringern, bieten Browser eine isolierte, auf Opt-in-Basis basierende Umgebung, die als ursprungsübergreifende Isolierung bezeichnet wird. Im ursprungsübergreifenden isolierten Status kann die Webseite privilegierte Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und hochpräzise Timer mit besserer Auflösung verwenden und gleichzeitig den Ursprung von anderen isoliert, sofern dies nicht aktiviert ist.

Bisher musste Cross-Origin-Opener-Policy: same-origin festgelegt werden, um diese APIs verwenden zu können. Dadurch würden jedoch alle ursprungsübergreifenden Pop-up-Abläufe wie die Einmalanmeldung (SSO) und Zahlungen unterbrochen, die du möglicherweise benötigst.

Cross-Origin-Opener-Policy: restrict-properties kann jetzt anstelle von Cross-Origin-Opener-Policy: same-origin verwendet werden, um die ursprungsübergreifende Isolierung zu aktivieren. Anstatt die offenere Beziehung zu trennen, wird sie einfach auf die minimale Kommunikationsteilmenge von window.postMessage() und window.closed beschränkt.

Sie können die ursprungsübergreifende Isolierung mit den folgenden beiden Headern aktivieren:

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: require-corp

oder

Cross-Origin-Opener-Policy: restrict-properties
Cross-Origin-Embedder-Policy: credentialless

Weitere Informationen zu credentialless finden Sie unter Cross-Origin-Ressourcen ohne CORP-Header mit COEP: credentialless laden.

Demo

In dieser Demo zur ursprungsübergreifenden Isolierung können Sie verschiedene Headeroptionen ausprobieren.

Mit dem Ursprungstest experimentieren

Wenn Sie mit Cross-Origin-Opener-Policy: restrict-properties experimentieren möchten, aktivieren Sie den Ursprungstest.

Unterstützte Browser

Cross-Origin-Opener-Policy: restrict-properties wird derzeit nur in Chrome unterstützt. Auch andere Browser beteiligt sich aktiv an der Diskussion über Standardisierung.

Häufig gestellte Fragen

Meine Website muss mit Pop-ups mit demselben Ursprung kommunizieren. Soll ich `COOP: restrict-properties` verwenden, um die ursprungsübergreifende Isolierung zu aktivieren?

Wenn du COOP: restrict-properties sowohl im Pop-up als auch auf deiner Hauptseite festlegst, führt das nicht zu Einschränkungen. Wenn Sie ihn entweder nur im Pop-up oder nur auf der Hauptseite festlegen, wird der Zugriff auf andere Attribute als postMessage und closed über die Opener-Seite verhindert, selbst wenn sie denselben Ursprung haben.

Ist der Satz zulässiger Eigenschaften unveränderlich?

Basierend auf dem bisherigen Feedback gehen wir davon aus, dass window.postMessage und window.closed für die meisten Workflows ausreichen. Wir ziehen jedoch weiterhin in Betracht, sie für andere Attribute zu öffnen. Wenn Sie einen Anwendungsfall haben, der nicht nur mit postMessage und closed gelöst werden kann, geben Sie Ihr Feedback im Thread „Intent to Test“.