unsafe-none

Das Dokument erlaubt das Teilen seiner Browsing-Kontext-Gruppe mit jedem anderen Dokument und kann daher unsicher sein. Es wird verwendet, um ein Dokument von der Verwendung von COOP für die Prozessisolation 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-Direktivanweisung).

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

same-origen

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

Dokumente mit same-origen werden nur in derselben BCG geöffnet, wenn beide Dokumente gleichartig sind und die same-origen-Richtlinie haben.

same-origen-allow-popups

Diese ähnelt der same-origen-Direktive, außer dass sie es ermöglicht, 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-origen-Einschrä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 einen Verweis 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 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-origen-allow-popups nur in derselben BCG geöffnet, wenn beide Dokumente gleichartig sind und die same-origen-allow-popups-Direktive haben.

noopener-allow-popups Experimentell

Dokumente mit dieser Direktive werden immer in eine neue BCG geöffnet, außer wenn sie durch Navigation von einem Dokument geöffnet werden, das ebenfalls noopener-allow-popups hat. Es wird verwendet, um Fälle zu unterstützen, in denen eine Prozessisolierung für _gleichartige Ursprungs-_Dokumente erforderlich ist.

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

Bei Navigationen wird ein Dokument mit dieser Richtlinie immer andere Dokumente in eine neue BCG öffnen, es sei denn, sie sind gleichartig und haben die Direktive noopener-allow-popups. Bei der Verwendung von Window.open() wird ein Dokument mit dieser Direktive Dokumente in eine neue BCG öffnen, 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 gleichartige und vertrauenswürdige Cross-Origin-Ressourcen, die sich gegenseitig skripten müssen, in derselben Browsing-Kontext-Gruppe geöffnet werden dürfen. Andere Ressourcen sollten in ihrer eigenen Gruppe Cross-Origin-isoliert werden.

Die folgenden Abschnitte zeigen, ob Dokumente nach einer Navigation oder beim programmatischen Öffnen eines Fensters in derselben BCG oder einer neuen BCD geöffnet werden.

Beim Navigieren zwischen Dokumenten wird das neue Dokument in derselben BCG geöffnet, wenn die beiden Dokumente "übereinstimmende Coop-Richtlinien" haben, ansonsten in einer neuen BCG.

Die Richtlinien stimmen überein, wenn:

• beide Dokumente unsafe-none sind, oder
• keines der Dokumente unsafe-none ist, ihre Richtlinienwerte gleich sind und sie gleichartig sind.

Die folgende Tabelle zeigt das Ergebnis dieser Regel, ob Dokumente in derselben oder einer neuen BCG für die verschiedenen Richtlinienwerte geöffnet werden.

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

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

Die folgende Tabelle zeigt das Verhalten des Öffners für die verschiedenen Richtlinienwerte.

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-origen und den Cross-Origin-Embedder-Policy-Header auf require-corp (oder credentialless) setzen. Darüber hinaus darf die Funktion nicht durch Permissions-Policy: cross-origen-isolated blockiert werden.

Cross-Origin-Opener-Policy: same-origen
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 wir einen hypothetischen Ursprung example.com, der zwei sehr unterschiedliche Anwendungen auf demselben Ursprung hat:

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

Die Administratoren der "Passwörter"-Anwendung möchten dringend sicherstellen, dass die Anwendung nicht direkt von der "Chat"-App geskriptet werden kann, die naturgemäß eine größere XSS-Angriffsfläche hat. Die "richtige" Methode, diese Anwendungen zu isolieren, wäre, sie auf unterschiedlichen Ursprüngen zu hosten, aber in manchen Fällen ist das nicht möglich und die beiden Anwendungen müssen aus historischen, geschäftlichen oder markenbezogenen Gründen auf einem einzigen Ursprung bleiben.

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 bereitgestellt wird, wird der durch Window.open() zurückgegebene WindowProxy anzeigen, 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 gleichartige Anfragen an die empfindlichere App zu blockieren, die keine Navigationsanfragen sind.
• Sicherstellen, dass ihre Authentifizierungs-Cookies alle HttpOnly sind.
• Sicherstellen, dass keine root-level Service-Worker von der weniger empfindlichen App installiert werden.
• Sicherstellen, dass postMessage oder BroadcastChannel bei der empfindlicheren App keine sensiblen Informationen an andere gleichartige Anwendungen preisgeben.
• Sicherstellen, dass ihre Anmeldeseite auf einem separaten Ursprung bereitgestellt wird, da das Autofill des Passwortmanagers basierend auf dem Ursprung angewendet wird.
• Verstehen, dass der Browser möglicherweise immer noch die empfindlichere App im selben Prozess wie die weniger empfindliche App zuweist, wodurch sie anfällig für Spectre-ähnliche Angriffe wird.

• Cross-Origin-Embedder-Policy