Der HTTPCross-Origin-Opener-Policy (COOP)Antwort-Header ermöglicht es einer Website, zu kontrollieren, ob ein neues oberstes Dokument, das mitWindow.open() geöffnet oder durch Navigieren zu einer neuen Seite erstellt wird, im gleichenBrowsing-Kontext (BCG) oder in einem neuen Browsing-Kontext geöffnet wird.

Wenn es in einem neuen BCG geöffnet wird, werden alle Referenzen zwischen dem neuen Dokument und seinem Öffner getrennt, und das neue Dokument kann prozessisoliert von seinem Öffner sein. Dies stellt sicher, dass potenzielle Angreifer Ihre Dokumente nicht mitWindow.open() öffnen und den zurückgegebenen Wert nutzen können, um auf dessen globales Objekt zuzugreifen, was eine Reihe von Cross-Origin-Angriffen, bekannt alsXS-Leaks, verhindert.

Es bedeutet auch, dass jedes Objekt, das Ihr Dokument in einem neuen BCG öffnet, nicht mitwindow.opener darauf zugreifen kann. Dies ermöglicht Ihnen mehr Kontrolle über Verweise auf ein Fenster alsrel=noopener, was ausgehende Navigationen betrifft, aber nicht Dokumente, die mitWindow.open() geöffnet wurden.

Das Verhalten hängt von den Richtlinien sowohl des neuen Dokuments als auch seines Öffners ab und davon, ob das neue Dokument nach einer Navigation oder mitWindow.open() geöffnet wird.

Syntax

Cross-Origin-Opener-Policy: unsafe-noneCross-Origin-Opener-Policy: same-origin-allow-popupsCross-Origin-Opener-Policy: same-originCross-Origin-Opener-Policy: noopener-allow-popups

Direktiven

unsafe-none

Das Dokument erlaubt die gemeinsame Nutzung seines Browsing-Kontextes mit jedem anderen Dokument und kann daher unsicher sein.Es wird verwendet, um ein Dokument von der Nutzung von COOP zur Prozessisolierung abzumelden.Dies ist der Standardwert.

Bei Navigationen werden Dokumente mitunsafe-none immer in einem neuen BCG geöffnet, es sei denn, das andere Dokument hat ebenfallsunsafe-none (oder keinen COOP-Direktivwert).

Bei der Verwendung vonWindow.open() öffnen Dokumente mitunsafe-none immer Dokumente mit einem anderen Wert in einem neuen BCG.Dokumente mitunsafe-none können jedoch im gleichen BCG geöffnet werden, wenn der Öffner die Direktivesame-origin-allow-popups,noopener-allow-popups oderunsafe-none hat.Ein Dokument mitsame-origin wird immer ein Dokument mitunsafe-none in einem neuen BCG öffnen.

same-origin

Das Dokument erlaubt das Laden in BCGs, die COOP verwenden und nur gleichherkunftliche Dokumente enthalten.Dies wird verwendet, umCross-Origin-Isolation für ein BCG bereitzustellen.

Dokumente mitsame-origin werden nur dann im gleichen BCG geöffnet und geöffnet, wenn beide Dokumente gleichherkunftlich sind und die Direktivesame-origin haben.

same-origin-allow-popups

Dies ist ähnlich wie diesame-origin-Direktive, erlaubt jedoch das Öffnen von Dokumenten mitWindow.open() im gleichen BCG, wenn sie einen COOP-Wert vonunsafe-none haben.

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

Ein Dokument mit dieser Direktive kann ein Dokument im gleichen BCG mitWindow.open() öffnen, wenn es einen COOP-Wert vonunsafe-none hat.In diesem Fall spielt es keine Rolle, ob das geöffnete Dokument crossing-site oder same-site ist.

Andernfalls werden Dokumente mitsame-origin-allow-popups nur dann im gleichen BCG geöffnet und geöffnet, wenn beide Dokumente gleichherkunftlich sind und die Direktivesame-origin-allow-popups haben.

noopener-allow-popups

Dokumente mit dieser Direktive werden immer in einem neuen BCG geöffnet, außer wenn sie durch Navigieren von einem Dokument geöffnet werden, das ebenfallsnoopener-allow-popups hat.Es wird verwendet, um Fälle zu unterstützen, in denen eine Prozessisolierung vongleichherkunftlichen Dokumenten erforderlich ist.

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

Bei Navigationen wird ein Dokument mit dieser Direktive immer andere Dokumente in einem neuen BCG öffnen, es sei denn, sie sind gleichherkunftlich und haben die Direktivenoopener-allow-popups.Bei der Verwendung vonWindow.open() wird ein Dokument mit dieser Direktive Dokumente in einem neuen BCG öffnen, es sei denn, sie habenunsafe-none, und in diesem Fall spielt es keine Rolle, ob sie same-site oder cross-site sind.

Beschreibung

Im Allgemeinen sollten Sie Ihre Richtlinien so festlegen, dass nur gleichherkunftliche und vertrauenswürdige Cross-Origin-Ressourcen, die sich gegenseitig skripten müssen, im gleichen Browsing-Kontext geöffnet sein dürfen. Andere Ressourcen sollten cross-origin in ihrer eigenen Gruppe isoliert sein.

Die folgenden Abschnitte zeigen, ob Dokumente nach einer Navigation oder dem programmatischen Öffnen eines Fensters im gleichen oder einem neuen BCG geöffnet werden.

Navigationen

Beim Navigieren zwischen Dokumenten wird das neue Dokument im gleichen BCG geöffnet, wenn die beiden Dokumente "übereinstimmende coop-Richtlinien" haben, und ansonsten in einem neuen BCG.

Die Richtlinien stimmen überein, wenn entweder beide Dokumente die Richtlinieunsafe-none haben oder wenn die Richtlinien gleich sind und die Dokumente gleichherkunftlich sind.

Die folgende Tabelle zeigt, wie diese Regel beeinflusst, ob Dokumente im gleichen oder einem neuen BCG für die verschiedenen Direktivenwerte geöffnet werden.

Öffnen mit Window.open()

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

1. Wenn das neue Dokument COOP aufnoopener-allow-popups gesetzt hat => öffne das neue Dokument in einem neuen BCG
2. Wenn das neue Dokument COOP aufunsafe-none gesetzt hat und das Öffnerdokument COOP auf entwedersame-origin-allow-popups odernoopener-allow-popups gesetzt hat => öffne das neue Dokument im gleichen BCG
3. Wenn das neue Dokument und das öffnende Dokumentübereinstimmende COOP-Richtlinien haben => öffne das neue Dokument im gleichen BCG
4. Andernfalls öffne das neue Dokument in einem neuen BCG

Die folgende Tabelle zeigt, wie diese Regeln beeinflussen, ob Dokumente im gleichen oder einem neuen BCG für die verschiedenen Direktivenwerte geöffnet werden.

Beispiele

Funktionen, die von Cross-Origin-Isolation abhängen

Bestimmte Funktionen, wie der Zugriff aufSharedArrayBuffer-Objekte oder die Verwendung vonPerformance.now() mit ungedrosselten Timern, sind nur verfügbar, wenn Ihr Dokumentcross-origin isoliert ist.

Um diese Funktionen in einem Dokument zu nutzen, müssen Sie den COOP-Header aufsame-origin und denCross-Origin-Embedder-Policy-Header aufrequire-corp (odercredentialless) setzen. Zudem darf die Funktion nicht durchPermissions-Policy: cross-origin-isolated blockiert werden.

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

Sie können die EigenschaftenWindow.crossOriginIsolated undWorkerGlobalScope.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);}

Trennen der Öffner-Beziehung

Betrachten Sie einen hypothetischen Ursprungexample.com, der zwei sehr unterschiedliche Anwendungen auf demselben Ursprung hat:

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

Die Administratoren der "Passwort"-Anwendung möchten unbedingt sicherstellen, dass diese nicht direkt durch die "Chat"-App geskriptet werden kann, die von Natur aus eine größere XSS-Oberfläche hat.Der "richtige Weg", um diese Anwendungen zu isolieren, wäre, sie auf verschiedenen 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 markentechnischen Gründen auf einem einzigen Ursprung sein.

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

Wennexample.com/passwords mitnoopener-allow-popups bereitgestellt wird, wird das vonWindow.open() zurückgegebeneWindowProxy angeben, dass das Fenster geschlossen ist (Window.closed isttrue), 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 Website muss auch Folgendes tun:

• Fetch-Metadaten verwenden, um gleichherkunftliche Anfragen an die sensiblere App zu blockieren, die keine Navigationsanfragen sind.
• Sicherstellen, dass alle AuthentifizierungscookiesHttpOnly sind.
• Sicherstellen, dass keine Root-Level-Service-Worker von der weniger sensiblen App installiert sind.
• Sicherstellen, dasspostMessage oderBroadcastChannel auf der sensibleren App keine sensiblen Informationen an eine andere gleichherkunftliche App preisgeben.
• Sicherstellen, dass die Anmeldeseite auf einem separaten Ursprung bereitgestellt wird, da die Autofill-Funktion des Passwortmanagers basierend auf dem Ursprung angewendet wird.
• Verstehen, dass der Browser die sensiblere App möglicherweise immer noch im gleichen Prozess wie die weniger sensible App zuweist und sie so anfällig für Spectre-ähnliche Angriffe macht.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Cross-Origin-Embedder-Policy