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 Verwendung von COOP für die Prozessisolierung auszuschließen. Dies ist der Standardwert.

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

Bei 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äre Dokumente enthalten. Dies wird verwendet, um Cross-Origin-Isolierung für eine BCG zu ermöglichen.

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

same-origin-allow-popups

Dies ist ähnlich zur same-origin-Direktive, erlaubt jedoch das Öffnen von Dokumenten mit Window.open() in derselben BCG, 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-Isolierung benötigt, aber auch ein vertrauenswürdiges Cross-Origin-Dokument öffnen und eine Referenz darauf behalten muss. Beispielsweise 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.

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

noopener-allow-popups Experimentell

Dokumente mit dieser Direktive werden immer in eine neue BCG geöffnet, es sei denn, sie werden durch Navigation von einem Dokument mit noopener-allow-popups geöffnet. Es wird verwendet, um Fälle zu unterstützen, in denen eine Notwendigkeit besteht, gleich-originäre Dokumente prozessisoliert zu halten.

Dies trennt die Verbindungen zwischen dem neuen Dokument und seinem Öffner, isoliert den Browsing-Kontext für das aktuelle Dokument unabhängig von 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är sind.

Bei Navigationen öffnet ein Dokument mit dieser Direktive immer andere Dokumente in einer neuen BCG, es sei denn, sie sind gleich-originär 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 same-site oder cross-site sind.

Im Allgemeinen sollten Sie Ihre Richtlinien so festlegen, dass nur gleich-originäre und vertrauenswürdige Cross-Origin-Ressourcen, die sich gegenseitig skripten müssen, in derselben Browsing-Kontextgruppe geöffnet werden dürfen. Andere Ressourcen sollten in ihrer eigenen Gruppe cross-origin isoliert werden.

Die folgenden Abschnitte zeigen, ob Dokumente im selben BCG oder einem neuen BCG geöffnet werden, nachdem eine Navigation erfolgt oder ein Fenster programmgesteuert geöffnet wurde.

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

Die Richtlinien stimmen überein, wenn:

• beide Dokumente unsafe-none sind, oder
• keines der Dokumente unsafe-none ist, ihre Richtlinienwerte identisch sind und sie gleich-originär sind.

Die folgende Tabelle zeigt das Ergebnis dieser Regel, ob Dokumente im selben oder einem neuen BCG für die verschiedenen Direktivenwerte geöffnet werden.

Beim Öffnen eines Dokuments mittels Window.open(), wird das neue Dokument in der selben BCG gemäß der folgenden Regeln geöffnet, die in der Reihenfolge ausgewertet werden:

1. Wahr: geöffnet noopener-allow-popups
2. Falsch: (opener same-origin-allow-popups oder noopener-allow-popups) und (geöffnetes Dokument ist unsafe-none)
3. Falsch: Übereinstimmende COOP-Richtlinien (wie oben für Navigationsprozesse beschrieben)
4. Wahr: Andernfalls!

Die folgende Tabelle zeigt das Öffnungsverhalten für die verschiedenen Direktivenwerte.

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 damit ob die Funktionen eingeschränkt sind oder nicht:

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 verschiedene Anwendungen auf demselben Ursprung hat:

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

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

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

Wenn example.com/passwords mit noopener-allow-popups bedient wird, zeigt das WindowProxy-Objekt, das von Window.open() zurückgegeben wird, an, dass das Fenster geschlossen ist (Window.closed ist true), sodass der Öffner die Passwörter-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:

• Verwenden von Fetch Metadata, um gleich-originäre Anfragen zu blockieren, die keine Navigationsanfragen an die sensiblere App sind.
• Sicherstellen, dass ihre Authentifizierungs-Cookies alle HttpOnly sind.
• Sicherstellen, dass root-level-Service-Worker nicht von der weniger sensiblen App installiert werden.
• Sicherstellen, dass postMessage oder BroadcastChannel auf der sensibleren App keine sensiblen Informationen an andere gleich-originäre Apps preisgibt.
• Sicherstellen, dass ihre Login-Seite 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 dennoch im selben Prozess wie die weniger sensible App allokieren kann, was sie anfällig für Spectre-ähnliche Angriffe macht.

• Cross-Origin-Embedder-Policy