Diese Seite wurde von der Cloud Translation API übersetzt.

Sichere Pop-up-Interaktionen mit Einschränkungseigenschaften

Sie erhalten eine plattformübergreifende Isolierung und einen plattformübergreifenden Schutz vor Datenlecks, wenn Sie mit Pop-ups interagieren.

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 Cross-Origin-Isolation. Außerdem kann Ihre Website mit Pop-ups von Drittanbietern für Zahlungen, Authentifizierung oder andere Anwendungsfälle interagieren.

Wenn Sie mit restrict-properties experimentieren möchten, nehmen Sie ab Chrome 116 am Ursprungstest teil.

Vorteile von `restrict-properties`

restrict-properties hat zwei Hauptanwendungsfälle:

Websiteübergreifende Datenlecks verhindern, ohne die Website zu beeinträchtigen.
Sorgen Sie dafür, dass Ihre Website ursprungsübergreifend isoliert ist.

Websiteübergreifende Datenlecks verhindern, ohne die Nutzerfreundlichkeit zu beeinträchtigen

Standardmäßig kann jede Website Ihre Anwendung in einem Pop-up öffnen und eine Referenz dazu abrufen.

Eine schädliche Website kann dies zu ihrem Vorteil nutzen, um Angriffe wie Cross-Site-Leaks durchzuführen. Um dieses Risiko zu minimieren, können Sie den Cross-Origin-Opener-Policy-Header (COOP) verwenden.

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

Legen Sie same-origin, fest, mit dem alle ursprungsübergreifenden Interaktionen mit Pop-ups blockiert werden.
Legen Sie same-origin-allow-popups fest, um alle plattformübergreifenden Interaktionen zu blockieren, die Ihre Website in einem Pop-up öffnen.
Legen Sie unsafe-none fest, um alle ursprungsübergreifenden Interaktionen mit Pop-ups zuzulassen.

Dadurch war es für Websites, die in einem Pop-up geöffnet werden müssen und mit ihrem Opener interagieren müssen, unmöglich, COOP zu erzwingen. Das hat dazu geführt, dass wichtige Anwendungsfälle wie die Einmalanmeldung und Zahlungen nicht vor websiteübergreifenden Datenlecks geschützt waren.

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

Mit restrict-properties sind Attribute, die für die Frame-Zählung und andere websiteübergreifende Leak-Angriffe verwendet werden können, nicht verfügbar. Eine grundlegende Kommunikation zwischen Fenstern über postMessage und closed ist jedoch zulässig.

So wird die Sicherheit einer Website verbessert, ohne wichtige Anwendungsfälle zu beeinträchtigen. Beispiel:

Wenn Sie einen Dienst in einem Pop-up anbieten, können Sie sich mit der Einstellung Cross-Origin-Opener-Policy: restrict-properties vor einer Reihe von websiteübergreifenden Leak-Angriffen schützen. Sie können weiterhin alle Seiten öffnen, die Sie zuvor geöffnet haben.
Wenn Sie auf ein Pop-up mit unterschiedlichen Ursprungswebsites zugreifen müssen, wird Ihre Website durch die Einstellung Cross-Origin-Opener-Policy: restrict-properties ebenfalls vor der iframe-Zählung geschützt. Sie können dieselben Pop-ups öffnen wie heute.
Wenn sowohl der Öffner als auch der Öffnete den Header festlegen und die Seiten unterschiedliche Ursprünge haben, verhält es sich ähnlich wie bei einer Seite, auf der nur einer der beiden den Header festgelegt hat. Wenn sie aus derselben Quelle stammen, wird der volle Zugriff gewährt.

Website ursprungsübergreifend isolieren

Warum ist die ursprungsübergreifende Isolierung erforderlich?

Einige Web-APIs erhöhen das Risiko von Seitenkanalangriffen wie Spectre. Um dieses Risiko zu minimieren, bieten Browser eine isolierte Umgebung mit Opt-in-Funktion namens Cross-Origin-Isolation. Bei einem plattformübergreifenden isolierten Zustand kann die Webseite privilegierte Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und High-Precision-Timer mit besserer Auflösung verwenden und den Ursprung von anderen isolieren, sofern diese nicht aktiviert sind.

Bisher mussten Sie Cross-Origin-Opener-Policy: same-origin festlegen, um diese APIs zu verwenden. Dadurch würde jedoch jeder ursprungsübergreifende Pop-up-Ablauf unterbrochen, den du möglicherweise benötigst, z. B. die Einmalanmeldung (SSO) und Zahlungen.

Cross-Origin-Opener-Policy: restrict-properties kann jetzt anstelle von Cross-Origin-Opener-Policy: same-origin verwendet werden, um die plattformübergreifende Isolierung zu aktivieren. Anstatt die offene Beziehung zu trennen, wird sie lediglich auf den minimalen Kommunikationsteil von window.postMessage() und window.closed beschränkt.

Sie können die plattformübergreifende Isolation 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 Ressourcen zwischen verschiedenen Ursprüngen ohne CORP-Header mit COEP: credentialless laden.

Demo

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

Ursprungstest ausprobieren

Wenn Sie Cross-Origin-Opener-Policy: restrict-properties testen möchten, aktivieren Sie den Test für den Ursprung.

Unterstützte Browser

Cross-Origin-Opener-Policy: restrict-properties wird derzeit nur in Chrome unterstützt. Andere Browser beteiligen sich aktiv an der Diskussion zur Standardisierung.

FAQ

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

Wenn Sie COOP: restrict-properties sowohl für das Pop-up als auch für Ihre Hauptseite festlegen, führt das nicht zu Einschränkungen. Wenn Sie die Einstellung entweder nur für das Pop-up oder nur für die Hauptseite festlegen, wird der Zugriff über den Auslöser auf alle Properties außer postMessage und closed verhindert, auch wenn sie dieselbe Quelle haben.

Ist die Liste der zulässigen Properties festgelegt?

Basierend auf dem bisherigen Feedback gehen wir davon aus, dass window.postMessage und window.closed für die meisten Workflows ausreichen. Wir überlegen aber trotzdem, die Funktion für weitere Properties zu öffnen. Wenn Sie einen Anwendungsfall haben, der nicht nur mit postMessage und closed gelöst werden kann, hinterlassen Sie Ihr Feedback in diesem Thread.