Cross-Origin-Opener-Policy

unsafe-none

Das Dokument erlaubt das Teilen seiner Browsing-Kontextgruppe mit jedem anderen Dokument und kann daher unsicher sein. Es wird verwendet, um ein Dokument von der Nutzung von COOP zur Prozessisolierung auszuschließen. Dies ist der Standardwert.

Bei Navigationen werden Dokumente mit unsafe-none immer in eine neue BCG geöffnet und geöffnet — es sei denn, das andere Dokument hat ebenfalls unsafe-none (oder keine COOP-Direktive).

Bei der Verwendung von Window.open() öffnen Dokumente mit unsafe-none immer Dokumente mit einem anderen Wert in eine neue BCG. Dokumente mit unsafe-none können jedoch in derselben BCG geöffnet werden, wenn der Öffner die Direktive same-origin-allow-popups, noopener-allow-popups oder unsafe-none hat. Ein Dokument mit same-origin öffnet immer ein Dokument mit unsafe-none in einer neuen BCG.

same-origin

Das Dokument erlaubt das Laden in BCGs, die COOP verwenden und nur gleich-origin-Dokumente enthalten. Dies wird verwendet, um Cross-Origin-Isolation für eine BCG bereitzustellen.

Dokumente mit same-origin werden nur dann in derselben BCG geöffnet und geöffnet, wenn beide Dokumente gleich-origin sind und die Direktive same-origin haben.

same-origin-allow-popups

Dies ist ähnlich wie die same-origin Direktive, außer dass es erlaubt, Dokumente mit Window.open() in derselben BCG zu öffnen, wenn sie einen COOP-Wert von unsafe-none haben.

Die Direktive wird verwendet, um die same-origin Beschränkung für Integrationen zu lockern, bei denen ein Dokument die Vorteile der Cross-Origin-Isolation benötigt, aber auch vertrauenswürdige Cross-Origin-Dokumente öffnen und deren Referenzen behalten muss. Zum Beispiel bei der Verwendung eines Cross-Origin-Dienstes für OAuth oder Zahlungen.

Ein Dokument mit dieser Direktive kann ein Dokument in derselben BCG mit Window.open() öffnen, wenn es einen COOP-Wert von unsafe-none hat. In diesem Fall spielt es keine Rolle, ob das geöffnete Dokument Cross-Site oder Same-Site ist.

Andernfalls werden Dokumente mit same-origin-allow-popups nur dann in derselben BCG geöffnet und geöffnet, wenn beide Dokumente gleich-origin sind und die Direktive same-origin-allow-popups haben.

noopener-allow-popups

Dokumente mit dieser Direktive werden immer in eine neue BCG geöffnet, außer wenn sie durch Navigieren von einem Dokument geöffnet werden, das ebenfalls noopener-allow-popups hat. Es wird verwendet, um Fälle zu unterstützen, in denen gleich-origin Dokumente prozessisoliert werden müssen.

Dies trennt die Verbindungen zwischen dem neuen Dokument und seinem Öffner, isoliert den Browsing-Kontext für das aktuelle Dokument ungeachtet der Herkunft des Öffnerdokuments. Dies stellt sicher, dass der Öffner keine Skripte in geöffneten Dokumenten ausführen kann und umgekehrt — selbst wenn sie gleich-origin sind.

Bei Navigationen öffnet ein Dokument mit dieser Direktive immer andere Dokumente in einer neuen BCG, es sei denn, sie sind gleich-origin und haben die Direktive noopener-allow-popups. Bei Verwendung von Window.open() öffnet ein Dokument mit dieser Direktive Dokumente in einer neuen BCG, es sei denn, sie haben unsafe-none, und in diesem Fall spielt es keine Rolle, ob sie gleich-seitig oder cross-seitig sind.

Im Allgemeinen sollten Sie Ihre Richtlinien so einstellen, dass nur gleich-origin und vertrauenswürdige Cross-Origin-Ressourcen, die in der Lage sein müssen, sich gegenseitig zu skripten, in der gleichen Browsing-Kontextgruppe geöffnet werden dürfen. Andere Ressourcen sollten in ihrer eigenen Gruppe Cross-Origin isoliert sein.

Die folgenden Abschnitte zeigen, ob Dokumente in derselben BCG oder einer neuen BCG geöffnet werden, nachdem eine Navigation erfolgt oder ein Fenster programmatisch geöffnet wird.

Bei der Navigation zwischen Dokumenten wird das neue Dokument in der gleichen BCG geöffnet, wenn die beiden Dokumente "übereinstimmende coop-Richtlinien" haben, und anderenfalls in eine neue BCG.

Die Richtlinien stimmen überein, wenn entweder beide Dokumente die Richtlinie unsafe-none haben oder wenn die Richtlinien gleich sind und die Dokumente gleich-origin sind.

Die folgende Tabelle zeigt, wie diese Regel beeinflusst, ob Dokumente in derselben oder einer neuen BCG für die verschiedenen Direktivwerte geöffnet werden.

Beim Öffnen eines Dokuments mit Window.open() wird das neue Dokument gemäß den folgenden Regeln, die der Reihe nach ausgewertet werden, in einer neuen BCG geöffnet:

1. Wenn das neue Dokument COOP auf noopener-allow-popups gesetzt hat => öffne das neue Dokument in einer neuen BCG
2. Wenn das neue Dokument COOP auf unsafe-none gesetzt hat und das Öffnerdokument COOP entweder auf same-origin-allow-popups oder noopener-allow-popups gesetzt hat => öffne das neue Dokument in derselben BCG
3. Wenn das neue Dokument und das öffnende Dokument übereinstimmende COOP-Richtlinien haben => öffne das neue Dokument in derselben BCG
4. Andernfalls öffnen Sie das neue Dokument in einer neuen BCG

Die folgende Tabelle zeigt, wie diese Regeln beeinflussen, ob Dokumente in der gleichen oder einer neuen BCG für die verschiedenen Direktivwerte geöffnet werden.

Bestimmte Funktionen, wie der Zugriff auf SharedArrayBuffer-Objekte oder die Verwendung von Performance.now() mit ungedrosselten Timern, sind nur verfügbar, wenn Ihr Dokument Cross-Origin isoliert ist.

Um diese Funktionen in einem Dokument zu verwenden, müssen Sie den COOP-Header auf same-origin und den Cross-Origin-Embedder-Policy-Header auf require-corp (oder credentialless) setzen. Zusätzlich darf die Funktion nicht durch Permissions-Policy: cross-origin-isolated blockiert werden.

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

Sie können die Eigenschaften Window.crossOriginIsolated und WorkerGlobalScope.crossOriginIsolated verwenden, um zu überprüfen, ob ein Dokument Cross-Origin isoliert ist und ob die Funktionen daher eingeschränkt sind:

const myWorker = new Worker("worker.js");

if (crossOriginIsolated) {
  const buffer = new SharedArrayBuffer(16);
  myWorker.postMessage(buffer);
} else {
  const buffer = new ArrayBuffer(16);
  myWorker.postMessage(buffer);
}

Betrachten Sie einen hypothetischen Ursprung example.com, der zwei sehr unterschiedliche Anwendungen auf dem gleichen Ursprung hat:

• Eine Chat-Anwendung unter /chat, die es jedem Benutzer ermöglicht, jeden anderen Benutzer zu kontaktieren und ihm Nachrichten zu senden.
• Eine Passwortverwaltungsanwendung unter /passwords, die alle Passwörter des Benutzers, über verschiedene Dienste hinweg, enthält.

Die Administratoren der "Passwörter"-Anwendung würden sehr gerne sicherstellen, dass sie nicht direkt von der "Chat"-App geskriptet werden kann, die aufgrund ihrer Natur eine größere XSS-Oberfläche hat. Der "richtige Weg", diese Anwendungen zu isolieren, wäre, sie auf unterschiedlichen Ursprüngen zu hosten, aber in einigen Fällen ist das nicht möglich, und diese beiden Anwendungen müssen aus historischen, geschäftlichen oder markenbezogenen Gründen auf einem einzigen Ursprung liegen.

Der Cross-Origin-Opener-Policy: noopener-allow-popups-Header kann verwendet werden, um sicherzustellen, dass ein Dokument nicht von einem Dokument geskriptet werden kann, das es öffnet.

Wenn example.com/passwords mit noopener-allow-popups ausgeliefert wird, zeigt der von Window.open() zurückgegebene WindowProxy an, dass das Fenster geschlossen ist (Window.closed ist true), sodass der Öffner die Passwort-App nicht skripten kann:

const handle = window.open("example.com/passwords", "passwordTab");
if (windowProxy.closed) {
  // The new window is closed so it can't be scripted.
}

Beachten Sie, dass dies allein nicht als ausreichende Sicherheitsmaßnahme angesehen wird. Die Seite müsste auch Folgendes tun:

• Fetch Metadata verwenden, um gleich-originige Anfragen an die sensiblere App zu blockieren, die keine Navigationsanfragen sind.
• Sicherstellen, dass alle Authentifizierungscookies HttpOnly sind.
• Sicherstellen, dass keine Root-Level-Service-Worker von der weniger sensiblen App installiert werden.
• Sicherstellen, dass postMessage oder BroadcastChannel in der sensibleren App keine sensitiven Informationen an eine andere gleich-originige App preisgeben.
• Sicherstellen, dass die Login-Seite auf einem separaten Ursprung bereitgestellt wird, da das automatische Ausfüllen des Passwort-Managers basierend auf dem Ursprung angewendet wird.
• Verstehen, dass der Browser die sensiblere App möglicherweise weiterhin im selben Prozess wie die weniger sensible App platziert, was sie anfällig für Spectre-ähnliche Angriffe macht.

• Cross-Origin-Embedder-Policy