Cross-Origin-Opener-Policy

unsafe-none

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

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

Mit Window.open() werden Dokumente mit unsafe-none immer in eine neue BCG geöffnet, wenn sie mit einem anderen Wert geöffnet werden. Allerdings können Dokumente mit unsafe-none in derselben BCG geöffnet werden, wenn der Urheber die Richtlinie 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-originierte Dokumente enthalten. Dies wird verwendet, um Cross-Origin-Isolierung für eine BCG bereitzustellen.

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

same-origin-allow-popups

Dies ist ähnlich der same-origin-Richtlinie, außer dass sie das Öffnen von Dokumenten mit Window.open() in derselben BCG erlaubt, wenn sie einen COOP-Wert von unsafe-none haben.

Die Richtlinie 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 eine Referenz zu vertrauenswürdigen Cross-Origin-Dokumenten öffnen und beibehalten muss. Zum Beispiel, wenn ein Cross-Origin-Dienst für OAuth oder Zahlungen verwendet wird.

Ein Dokument mit dieser Richtlinie 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 in derselben BCG geöffnet und hinein geöffnet, wenn beide Dokumente gleich-originig sind und die same-origin-allow-popups-Richtlinie haben.

noopener-allow-popups

Dokumente mit dieser Richtlinie werden immer in eine neue BCG geöffnet, außer wenn sie durch eine Navigation von einem Dokument geöffnet werden, das ebenfalls noopener-allow-popups hat. Es wird verwendet, um Fälle zu unterstützen, in denen es notwendig ist, gleich-originige Dokumente prozess-isoliert zu haben.

Dies trennt die Verbindungen zwischen dem neuen Dokument und seinem Urheber und isoliert den Browsing-Kontext für das aktuelle Dokument unabhängig von der Herkunft des Urheberdokuments. Dies stellt sicher, dass der Urheber keine Skripte in geöffneten Dokumenten ausführen kann und umgekehrt — selbst wenn sie gleich-originig sind.

Bei Navigationen wird ein Dokument mit dieser Richtlinie immer andere Dokumente in einer neuen BCG öffnen, es sei denn, sie sind gleich-originig und haben die Richtlinie noopener-allow-popups. Mit Window.open() wird ein Dokument mit dieser Richtlinie 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 gleich-originige und vertrauenswürdige Cross-Origin-Ressourcen, die sich gegenseitig skripten können sollen, in derselben Browser-Kontextgruppe geöffnet werden dürfen. Andere Ressourcen sollten in ihrer eigenen Gruppe Cross-Origin-isoliert sein.

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

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

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

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

Beim Öffnen eines Dokuments mit Window.open() wird das neue Dokument gemäß den folgenden Regeln, die in Reihenfolge 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 öffnende Dokument COOP auf entweder 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. Ansonsten öffne das neue Dokument in einer neuen BCG

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

Bestimmte Funktionen, wie der Zugriff auf SharedArrayBuffer-Objekte oder die Nutzung 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. Zudem darf die Funktion nicht durch die 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 somit ob die Funktionen 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 demselben Ursprung hat:

• Eine Chat-Anwendung unter /chat, die es jedem Benutzer ermöglicht, jeden anderen Benutzer zu kontaktieren und ihnen 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 skriptiert werden kann, die von Natur aus eine größere XSS-Oberfläche hat. Der "richtige Weg", 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 markenbezogenen Gründen auf einem einzigen Ursprung sein.

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

Wenn example.com/passwords mit noopener-allow-popups bereitgestellt wird, wird der von Window.open() zurückgegebene WindowProxy anzeigen, dass das Fenster geschlossen ist (Window.closed ist true), sodass der Erzeuger 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 betrachtet wird. Die Website müsste auch Folgendes tun:

• Verwenden Sie Fetch-Metadaten, um gleich-originige Anfragen zur sensibleren App zu blockieren, die keine Navigationsanfragen sind.
• Stellen Sie sicher, dass alle Authentifizierungs-Cookies HttpOnly sind.
• Stellen Sie sicher, dass root-level Service-Worker nicht von der weniger-sensiblen App installiert werden.
• Stellen Sie sicher, dass postMessage oder BroadcastChannel auf der mehr-sensiblen App keine sensiblen Informationen an jede andere gleich-originige App preisgeben.
• Stellen Sie sicher, dass die Anmeldeseite auf einem separaten Ursprung bereitgestellt wird, da der Auto-Ausfüllmanager basierend auf dem Ursprung angewendet wird.
• Verstehen Sie, dass der Browser die sensiblere App möglicherweise immer noch im selben Prozess wie die weniger sensible App zuweist, wodurch sie anfällig für Spectre-ähnliche Angriffe wird.

• Cross-Origin-Embedder-Policy