Website mit COOP und COEP „ursprungsübergreifend isoliert“ machen

Mit COOP und COEP können Sie eine ursprungsübergreifend isolierte Umgebung einrichten und leistungsstarke Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und einen hochauflösenden Timer mit besserer Genauigkeit aktivieren.

Eiji Kitamura

Veröffentlicht: 13. April 2020, zuletzt aktualisiert: 21. Juni 2022

Achtung: SharedArrayBuffer in Chrome für Computer erfordert ab Chrome 92 eine ursprungsübergreifende Isolation. Weitere Informationen finden Sie unter SharedArrayBuffer-Updates.

In diesem Dokument wird beschrieben, wie Sie COOP und COEP verwenden. Weitere Informationen dazu, warum dies wichtig ist, finden Sie unter Website mit COOP und COEP „ursprungsübergreifend isolieren“.

Einige Web-APIs erhöhen das Risiko von Seitenkanalangriffen wie Spectre. Um dieses Risiko zu minimieren, bieten Browser eine isolierte Umgebung, die auf einer Opt-in-Basis basiert und als „ursprungsübergreifend isoliert“ bezeichnet wird. In einem ursprungsübergreifend isolierten Zustand kann die Webseite privilegierte Funktionen verwenden, darunter:

Funktionen, die im ursprungsübergreifend isolierten Zustand verfügbar sind.

API	Beschreibung
SharedArrayBuffer	Erforderlich für WebAssembly-Threads. Diese Funktion ist ab Chrome 88 für Android verfügbar. Die Desktopversion ist standardmäßig mithilfe der Website-Isolierung aktiviert, erfordert jedoch den ursprungsübergreifend isolierten Status und wird in Chrome 92 standardmäßig deaktiviert.
performance.measureUserAgentSpecificMemory()	Verfügbar ab Chrome 89.
performance.now(), performance.timeOrigin	In vielen Browsern verfügbar, wobei die Auflösung auf 100 Mikrosekunden oder mehr beschränkt ist. Bei der ursprungsübergreifenden Isolation kann die Auflösung 5 Mikrosekunden oder höher sein.

Der ursprungsübergreifend isolierte Status verhindert auch Änderungen an document.domain. (Die Möglichkeit, document.domain zu ändern, ermöglicht die Kommunikation zwischen SameSite-Dokumenten und wurde als Lücke in der Same-Origin-Richtlinie angesehen.)

Wenn Sie die ursprungsübergreifende Isolierung aktivieren möchten, müssen Sie die folgenden HTTP-Header im Hauptdokument senden:

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

Diese Header weisen den Browser an, das Laden von Ressourcen oder iFrames zu blockieren, die nicht für das Laden durch ursprungsübergreifende Dokumente aktiviert wurden. Außerdem verhindern sie, dass ursprungsübergreifende Fenster direkt mit Ihrem Dokument interagieren. Das bedeutet auch, dass für diese ursprungsübergreifend geladenen Ressourcen eine Einwilligung erforderlich ist.

Ob eine Webseite ursprungsübergreifend isoliert ist, lässt sich anhand von self.crossOriginIsolated feststellen.

Hinweis: Dieses Dokument richtet sich an alle, die ihre Websites für die Verwendung von SharedArrayBuffer, WebAssembly-Threads, performance.measureUserAgentSpecificMemory() oder hochauflösenden Timern mit besserer Präzision und robusterer Leistung auf verschiedenen Browserplattformen vorbereiten möchten.

Glossar

In diesem Dokument werden viele ähnlich benannte und abgekürzte Begriffe verwendet. Zur Verdeutlichung haben wir ein kleines Glossar zusammengestellt:

• COEP: Cross Origin Embedder Policy
• COOP: Cross Origin Opener Policy
• CORP: Cross Origin Resource Policy
• CORS: Cross Origin Resource Sharing
• CORB: Cross Origin Read Blocking

Website ursprungsübergreifend isolieren

Tipp: Hier finden Sie praktische Schritte zum Aktivieren der ursprungsübergreifenden Isolation.

1. Cross-Origin-Opener-Policy: same-origin für das Dokument auf oberster Ebene festlegen

Wenn Sie COOP: same-origin für ein übergeordnetes Dokument aktivieren, haben Fenster mit demselben Ursprung und Fenster, die über das Dokument geöffnet werden, eine separate Browserkontextgruppe, es sei denn, sie haben denselben Ursprung und dieselbe COOP-Einstellung. Daher wird die Isolation für geöffnete Fenster erzwungen und die gegenseitige Kommunikation zwischen beiden Fenstern deaktiviert.

Eine Browsing-Kontextgruppe ist eine Gruppe von Fenstern, die aufeinander verweisen können. Beispiel: Ein Dokument der obersten Ebene und seine untergeordneten Dokumente, die mit <iframe> eingebettet sind. Wenn eine Website (https://a.example) ein Dialogfenster (https://b.example) öffnet, haben das Öffnerfenster und das Dialogfenster denselben Browserkontext. Daher können sie mit DOM APIs wie window.opener aufeinander zugreifen.

Sie können in den Entwicklertools prüfen, ob sich das Fenster, das ein anderes Fenster geöffnet hat, und das geöffnete Fenster in separaten Browserkontextgruppen befinden.

2. CORP oder CORS für Ressourcen aktivieren

Achten Sie darauf, dass alle Ressourcen auf der Seite mit CORP- oder CORS-HTTP-Headern geladen werden. Dieser Schritt ist für Schritt 4, das Aktivieren von COEP, erforderlich.

Je nach Art der Ressource müssen Sie Folgendes tun:

• Wenn die Ressource nur vom selben Ursprung geladen werden soll, legen Sie den Header Cross-Origin-Resource-Policy: same-origin fest.
• Wenn die Ressource nur von derselben Website, aber ursprungsübergreifend geladen werden soll, legen Sie den Header Cross-Origin-Resource-Policy: same-site fest.
• Wenn die Ressource von einem oder mehreren Cross-Origins geladen wird, die du kontrollierst, lege nach Möglichkeit den Header Cross-Origin-Resource-Policy: cross-origin fest.
• Für ursprungsübergreifende Ressourcen, über die Sie keine Kontrolle haben:
  • Verwenden Sie das Attribut crossorigin im HTML-Tag zum Laden, wenn die Ressource mit CORS bereitgestellt wird. (Zum Beispiel: <img src="***" crossorigin>).
  • Bitten Sie den Inhaber der Ressource, entweder CORS oder CORP zu unterstützen.
• Folgen Sie bei iFrames denselben Prinzipien und legen Sie Cross-Origin-Resource-Policy: cross-origin (oder same-site, same-origin, je nach Kontext) fest.
• Mit einem WebWorker geladene Scripts müssen vom selben Ursprung bereitgestellt werden. Sie benötigen also keine CORP- oder CORS-Header.
• Bei einem Dokument oder Worker, der mit COEP: require-corp bereitgestellt wird, muss für ursprungsübergreifende Unterressourcen, die ohne CORS geladen werden, der Header Cross-Origin-Resource-Policy: cross-origin festgelegt werden, damit sie eingebettet werden können. Das gilt beispielsweise für <script>, importScripts, <link>, <video>, <iframe> usw.

Schlüsselbegriff: Same-Site sind Websites mit demselben Schema und derselben eTLD+1. Same-Origin sind Websites, die dieselbe Kombination aus Schema, Hostname und Port haben. Weitere Informationen zum Unterschied zwischen „Same-Site“ und „Same-Origin“

Isolierung in iFrames

Sie können die ursprungsübergreifende Isolation für ein in einem iFrame eingebettetes Dokument aktivieren, indem Sie die Berechtigungsrichtlinie allow="cross-origin-isolated" auf das Tag <iframe> anwenden und die folgenden Bedingungen erfüllen. Die gesamte Kette der Dokumente, einschließlich über- und untergeordneter Frames, muss ebenfalls ursprungsübergreifend isoliert sein.

3. HTTP-Header „COEP Report-Only“ verwenden, um eingebettete Ressourcen zu bewerten

Bevor Sie COEP vollständig aktivieren, können Sie einen Probelauf mit dem Header Cross-Origin-Embedder-Policy-Report-Only durchführen, um zu prüfen, ob die Richtlinie tatsächlich funktioniert. Sie erhalten Berichte, ohne dass eingebettete Inhalte blockiert werden.

Wende dies rekursiv auf alle Dokumente an, einschließlich des Dokuments auf oberster Ebene, iFrames und Worker-Skripts. Informationen zum HTTP-Header „Report-Only“ finden Sie unter Probleme mit der Reporting API beobachten.

4. COEP aktivieren

Dieser Schritt ist erst möglich, wenn Sie sichergestellt haben, dass für Ressourcen CORP oder CORS aktiviert ist.

Nachdem Sie bestätigt haben, dass alles funktioniert und alle Ressourcen erfolgreich geladen werden können, ändern Sie den Header Cross-Origin-Embedder-Policy-Report-Only in den Header Cross-Origin-Embedder-Policy mit demselben Wert für alle Dokumente, einschließlich derer, die mit iFrames und Worker-Skripts eingebettet sind.

Hinweis: Squoosh, eine PWA zur Bildoptimierung, verwendet COOP/COEP, um Zugriff auf Wasm-Threads (und Shared Array Buffer) und auf Android Chrome zu erhalten.

Achtung: Wir untersuchen, wie wir Cross-Origin-Resource-Policy in großem Umfang bereitstellen können, da für die ursprungsübergreifende Isolierung alle Unterressourcen explizit aktiviert werden müssen. Eine Option ist der COEP-Modus ohne Anmeldedaten, mit dem Ressourcen ohne den CORP-Header geladen werden können, indem alle Anmeldedaten entfernt werden. Der Modus ohne Anmeldedaten ist ab Chrome 96 und in Edge verfügbar, wird aber noch nicht von anderen Browsern unterstützt.

Prüfen, ob die Isolierung erfolgreich war

Die Property self.crossOriginIsolated gibt true zurück, wenn sich die Webseite in einem ursprungsübergreifend isolierten Zustand befindet und alle Ressourcen und Fenster innerhalb derselben Browserkontextgruppe isoliert sind. Mit dieser API können Sie feststellen, ob Sie die Browsing-Kontextgruppe erfolgreich isoliert und Zugriff auf Funktionen wie performance.measureUserAgentSpecificMemory() erhalten haben.

Probleme beheben

Möglicherweise treten Probleme mit COOP und COEP auf. Sie können die Entwicklertools des Browsers oder die Reporting API zur Fehlerbehebung verwenden.

Debugging mit Chrome-Entwicklertools

Bei Ressourcen, die auf dem Bildschirm gerendert werden, z. B. Bildern, ist es relativ einfach, COEP-Probleme zu erkennen, da die Anfrage blockiert wird und auf der Seite ein fehlendes Bild angezeigt werden sollte. Bei Ressourcen, die nicht unbedingt visuelle Auswirkungen haben, z. B. Skripts oder Stile, bleiben COEP-Probleme jedoch möglicherweise unbemerkt. Verwenden Sie dafür den Netzwerkbereich der Entwicklertools.

Wenn ein Problem mit der COEP vorliegt, sollte in der Spalte Status (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) angezeigt werden.

Klicken Sie dann auf den Eintrag, um weitere Details aufzurufen.

Sie können den Status von iFrames und Dialogfeldern auch im Bereich Anwendung ermitteln. Gehen Sie links zum Abschnitt „Frames“ und maximieren Sie „top“, um die Aufschlüsselung der Ressourcenstruktur zu sehen.

Sie können den Status des iFrames prüfen, z. B. die Verfügbarkeit von SharedArrayBuffer.

Sie können auch den Status des Dialogfensters prüfen, z. B. ob es ursprungsübergreifend isoliert ist.

Probleme mit der Reporting API beobachten

Die Reporting API ist ein weiterer Mechanismus, mit dem du verschiedene Probleme erkennen kannst. Sie können die Reporting API so konfigurieren, dass der Browser Ihrer Nutzer einen Bericht sendet, wenn COEP das Laden einer Ressource blockiert oder COOP ein Dialogfenster isoliert. Chrome unterstützt die Reporting API seit Version 69 für eine Vielzahl von Anwendungen, einschließlich COEP und COOP.

Hinweis: Verwenden Sie die Reporting API bereits mit dem Header Report-To? Chrome stellt auf eine neue Version der Reporting API um, bei der Report-To durch Reporting-Endpoints ersetzt wird. Sie sollten auf die neue Version migrieren. Weitere Informationen finden Sie unter Zur Reporting API v1 migrieren.

Informationen zum Konfigurieren der Reporting API und zum Einrichten eines Servers für den Empfang von Berichten

Beispiel für einen COEP-Bericht

Ein Beispiel für eine COEP-Berichtsnutzlast, wenn eine ursprungsübergreifende Ressource blockiert wird, sieht so aus:

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.example.org/check.svg?",
    "blockedURL": "https://third-party-test.example.org/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.example.com/?coep=require-corp&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4249.0 Safari/537.36"
}]

Achtung: blocked-url ist nur aus Gründen der Abwärtskompatibilität vorhanden und wird entfernt.

Beispiel für einen COOP-Bericht

Eine Beispielnutzlast für einen COOP-Bericht, wenn ein Dialogfeld isoliert geöffnet wird, sieht so aus:

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.example.org/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.example.com/coop?coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

Wenn verschiedene Browserkontextgruppen versuchen, aufeinander zuzugreifen (nur im Modus „Nur Berichterstellung“), sendet COOP ebenfalls einen Bericht. Ein Bericht, wenn postMessage() versucht wird, würde beispielsweise so aussehen:

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.example.com/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.example.com/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
},
{
  "age": 51785,
  "body": {
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "property": "postMessage",
    "type": "access-to-coop-page-from-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.example.com/coop?report-only&coop=same-origin&",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4246.0 Safari/537.36"
}]

Fazit

Verwenden Sie eine Kombination aus COOP- und COEP-HTTP-Headern, um eine Webseite in einen speziellen ursprungsübergreifenden isolierten Zustand zu versetzen. Sie können self.crossOriginIsolated prüfen, um festzustellen, ob eine Webseite ursprungsübergreifend isoliert ist.

Wir werden diesen Beitrag aktualisieren, sobald neue Funktionen für diesen ursprungsübergreifend isolierten Status verfügbar sind und weitere Verbesserungen an den DevTools im Zusammenhang mit COOP und COEP vorgenommen werden.

Ressourcen

• Warum Sie für leistungsstarke Funktionen „ursprungsübergreifend isoliert“ benötigen
• Anleitung zum Aktivieren der ursprungsübergreifenden Isolierung
• Gesamte Speichernutzung Ihrer Webseite mit measureUserAgentSpecificMemory() überwachen

Dokumentaktualisierungen

• 21. Juni 2022: Worker-Skripts müssen ebenfalls sorgfältig behandelt werden, wenn die ursprungsübergreifende Isolation aktiviert ist. Added some explanations.
• 5. August 2021: Die JS Self-Profiling API wurde als eine der APIs erwähnt, die eine ursprungsübergreifende Isolation erfordern. Aufgrund der jüngsten Richtungsänderung wurde sie jedoch entfernt.
• 6. Mai 2021: Aufgrund von Feedback und gemeldeten Problemen haben wir beschlossen, den Zeitplan für die Einschränkung der Verwendung von SharedArrayBuffer auf Websites, die nicht ursprungsübergreifend isoliert sind, in Chrome M92 anzupassen.
• 16. April 2021: Hinweise zum COEP-Modus ohne Anmeldedaten und zu COOP-same-origin-allow-popups als weniger strenge Bedingung für die ursprungsübergreifende Isolation hinzugefügt.
• 5. März 2021: Einschränkungen für SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und Debugging-Funktionen wurden entfernt. Diese sind jetzt in Chrome 89 vollständig aktiviert. Zukünftige Funktionen, performance.now() und performance.timeOrigin, mit höherer Genauigkeit hinzugefügt.
• 19. Februar 2021: Hinweis zur Feature-Richtlinie allow="cross-origin-isolated" und zur Debugging-Funktion in den Entwicklertools hinzugefügt.
• 15. Oktober 2020: self.crossOriginIsolated ist ab Chrome 87 verfügbar. Dementsprechend ist document.domain unveränderlich, wenn self.crossOriginIsolated den Wert true zurückgibt. performance.measureUserAgentSpecificMemory() beendet den Ursprungstest und ist in Chrome 89 standardmäßig aktiviert. Shared Array Buffer in Chrome für Android ist ab Chrome 88 verfügbar.