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

Mit COOP und COEP können Sie eine plattformübergreifende, isolierte Umgebung einrichten und leistungsstarke Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und einen Timer mit hoher Auflösung mit besserer Präzision aktivieren.

Updates

  • 21. Juni 2022: Bei aktivierter plattformübergreifender Isolation müssen auch Worker-Scripts mit Bedacht verwendet werden. Es wurden einige Erläuterungen hinzugefügt.
  • 5. August 2021: Die JS Self-Profiling API wurde als eine der APIs erwähnt, für die eine ursprungsübergreifende Isolierung erforderlich ist. Aufgrund der aktuellen Richtungsänderung wurde sie 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 ohne ursprungsübergreifende Isolierung auf Chrome M92 anzupassen.
  • 16. April 2021: Es wurden Hinweise zum neuen COEP-Modus ohne Anmeldedaten und zur COOP-Richtlinie „same-origin-allow-popups“ als lockere Bedingung für die plattformübergreifende Isolation hinzugefügt.
  • 5. März 2021: Die Einschränkungen für SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und Debugging-Funktionen, die in Chrome 89 jetzt vollständig aktiviert sind, wurden entfernt. Es wurden die Funktionen performance.now() und performance.timeOrigin hinzugefügt, die eine höhere Präzision bieten.
  • 19. Februar 2021: Hinweis zur Funktionsweise von DevTools im Hinblick auf die Richtlinie zu Funktionenallow="cross-origin-isolated" hinzugefügt.
  • 15. Oktober 2020: self.crossOriginIsolated ist ab Chrome 87 verfügbar. Daher ist document.domain unveränderlich, wenn self.crossOriginIsolated true zurückgibt. performance.measureUserAgentSpecificMemory() beendet den Test für Ursprünge und aktiviert die Funktion in Chrome 89 standardmäßig. Shared Array Buffer in Android Chrome ist ab Chrome 88 verfügbar.

Einige Web-APIs erhöhen das Risiko von Side-Channel-Angriffen wie Spectre. Um dieses Risiko zu mindern, bieten Browser eine Opt-in-basierte isolierte Umgebung, die als ursprungsübergreifend isoliert bezeichnet wird. Mit einem plattformübergreifenden isolierten Status kann die Webseite privilegierte Funktionen verwenden, darunter:

API Beschreibung
SharedArrayBuffer Erforderlich für WebAssembly-Threads. Diese Funktion ist seit Android Chrome 88 verfügbar. Die Desktopversion ist derzeit standardmäßig mithilfe der Website-Isolierung aktiviert. Sie erfordert jedoch den ursprungsübergreifenden isolierten Status und wird in Chrome 92 standardmäßig deaktiviert.
performance.measureUserAgentSpecificMemory() Verfügbar ab Chrome 89.
performance.now(), performance.timeOrigin Derzeit in vielen Browsern verfügbar, wobei die Auflösung auf 100 Mikrosekunden oder mehr begrenzt ist. Bei der plattformübergreifenden Isolation kann die Auflösung 5 Mikrosekunden oder mehr betragen.
Funktionen, die nur im ursprungsübergreifend isolierten Zustand verfügbar sind.

Der ursprungsübergreifend isolierte Status verhindert außerdem Änderungen von document.domain. (Die Möglichkeit, document.domain zu ändern, ermöglicht die Kommunikation zwischen Dokumenten auf derselben Website und wurde als Schlupfloch in der Same-Origin-Richtlinie betrachtet.)

Wenn Sie den ursprungsübergreifenden isolierten Zustand 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 plattformübergreifende Dokumente aktiviert wurden. Außerdem wird verhindert, dass plattformübergreifende Fenster direkt mit Ihrem Dokument interagieren. Das bedeutet auch, dass für diese Ressourcen, die ursprungsübergreifend geladen werden, Einwilligungen erforderlich sind.

Ob eine Webseite sich in einem isolierten Cross-Origin-Zustand befindet, können Sie anhand von self.crossOriginIsolated feststellen.

In diesem Artikel erfahren Sie, wie Sie diese neuen Überschriften verwenden. In einem Folgeartikel werde ich weitere Hintergrundinformationen und Kontext liefern.

COOP und COEP bereitstellen, um Ihre Website plattformübergreifend zu isolieren

COOP und COEP einbinden

1. Cross-Origin-Opener-Policy: same-origin-Header im Dokument der obersten Ebene festlegen

Wenn Sie COOP: same-origin für ein Dokument der obersten Ebene aktivieren, haben Fenster mit demselben Ursprung und Fenster, die über das Dokument geöffnet werden, eine separate Gruppe für den Browserkontext, es sei denn, sie haben denselben Ursprung mit derselben COOP-Einstellung. So wird die Isolation für geöffnete Fenster erzwungen und die gegenseitige Kommunikation zwischen beiden Fenstern deaktiviert.

Eine Browser-Kontextgruppe besteht aus einer Reihe von Fenstern, die aufeinander verweisen können. Beispiel: ein Dokument der obersten Ebene und seine untergeordneten Dokumente, die über <iframe> eingebettet sind. Wenn durch eine Website (https://a.example) ein Pop-up-Fenster (https://b.example) geöffnet wird, teilen das Öffnungsfenster und das Pop-up-Fenster denselben Browserkontext, sodass sie über DOM-APIs wie window.opener aufeinander zugreifen können.

Gruppe „Browserkontext“

Sie können in den DevTools prüfen, ob sich der Fensteröffner und das geöffnete Fenster in separaten Browserkontextgruppen befinden.

2. Prüfen, ob für die Ressourcen CORP oder CORS aktiviert ist

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

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

  • Wenn die Ressource voraussichtlich nur von derselben Quelle geladen wird, legen Sie den Header Cross-Origin-Resource-Policy: same-origin fest.
  • Wenn die Ressource voraussichtlich nur von derselben Website, aber plattformübergreifend geladen wird, legen Sie den Header Cross-Origin-Resource-Policy: same-site fest.
  • Wenn die Ressource von einer oder mehreren von Ihnen kontrollierten Quellen geladen wird, legen Sie nach Möglichkeit den Header Cross-Origin-Resource-Policy: cross-origin fest.
  • Für plattformübergreifende Ressourcen, über die Sie keine Kontrolle haben:
    • Verwende das crossorigin-Attribut im HTML-Tag für das 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 wie oben und legen Sie je nach Kontext Cross-Origin-Resource-Policy: cross-origin (oder same-site, same-origin) fest.
  • Scripts, die mit einer WebWorker geladen werden, müssen vom selben Ursprung bereitgestellt werden. Daher sind keine CORP- oder CORS-Header erforderlich.
  • Bei einem Dokument oder Worker, das bzw. der mit COEP: require-corp gesendet wird, müssen für untergeordnete Ressourcen, die ohne CORS geladen werden, die Cross-Origin-Resource-Policy: cross-origin-Header festgelegt werden, um das Einbetten zu aktivieren. Das gilt beispielsweise für <script>, importScripts, <link>, <video> und <iframe>.

3. Nutzen Sie den COEP-Report-Only-HTTP-Header, um eingebettete Ressourcen zu bewerten.

Bevor Sie COEP vollständig aktivieren, können Sie mithilfe der Cross-Origin-Embedder-Policy-Report-Only-Überschrift einen Testlauf durchführen, um zu prüfen, ob die Richtlinie tatsächlich funktioniert. Sie erhalten Berichte, ohne eingebettete Inhalte zu blockieren.

Wende diese Änderung rekursiv auf alle Dokumente an, einschließlich des Dokuments auf oberster Ebene, Iframes und Worker-Scripts. Informationen zum HTTP-Header „Nur melden“ finden Sie unter Probleme mit der Reporting API beobachten.

4. COEP aktivieren

Sobald Sie bestätigt haben, dass alles funktioniert und alle Ressourcen erfolgreich geladen werden können, wechseln Sie bei allen Dokumenten, einschließlich derjenigen, die über iframes und Worker-Scripts eingebettet sind, von der Cross-Origin-Embedder-Policy-Report-Only-Überschrift zur Cross-Origin-Embedder-Policy-Überschrift mit demselben Wert.

Prüfen, ob die Isolation mit self.crossOriginIsolated erfolgreich war

Das Attribut 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 Browser-Kontextgruppe erfolgreich isoliert und Zugriff auf leistungsstarke Funktionen wie performance.measureUserAgentSpecificMemory() erhalten haben.

Probleme mit den Chrome-Entwicklertools beheben

Bei Ressourcen, die auf dem Bildschirm gerendert werden, z. B. Bildern, lassen sich COEP-Probleme relativ einfach erkennen, da die Anfrage blockiert wird und auf der Seite ein fehlendes Bild angezeigt wird. Bei Ressourcen, die nicht unbedingt eine visuelle Auswirkung haben, z. B. Scripts oder Stile, werden COEP-Probleme jedoch möglicherweise nicht bemerkt. Nutzen Sie dafür den Netzwerkbereich in den Entwicklertools. Wenn ein Problem mit COEP vorliegt, sollte in der Spalte Status (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) angezeigt werden.

COEP-Probleme in der Spalte „Status“ des Bereichs „Netzwerk“.

Klicken Sie dann auf den Eintrag, um weitere Details zu sehen.

Details zum COEP-Problem werden auf dem Tab „Headers“ (Header) angezeigt, nachdem Sie im Bereich „Network“ (Netzwerk) auf eine Netzwerkressource geklickt haben.

Sie können auch den Status von iFrames und Pop-up-Fenstern im Bereich Anwendung ermitteln. Maximieren Sie links den Bereich „Frames“ und maximieren Sie „oben“, um die Aufschlüsselung der Ressourcenstruktur zu sehen.

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

Iframe-Inspektor in den Chrome-Entwicklertools

Sie können auch den Status der Pop-up-Fenster prüfen, z. B. ob sie plattformübergreifend isoliert sind.

Chrome DevTools-Popup-Fenster-Inspektion

Probleme mithilfe der Reporting API beobachten

Die Reporting API ist ein weiterer Mechanismus, mit dem Sie verschiedene Probleme erkennen können. 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 Pop-up-Fenster isoliert. Chrome unterstützt die Reporting API seit Version 69 für eine Vielzahl von Anwendungen, darunter COEP und COOP.

Informationen zum Konfigurieren der Reporting API und zum Einrichten eines Servers für den Empfang von Berichten finden Sie unter Reporting API verwenden.

Beispiel für einen COEP-Bericht

Ein Beispiel für die Nutzlast eines COEP-Berichts, wenn eine ressourcenübergreifende Ressource blockiert wird, sieht so aus:

[{
  "age": 25101,
  "body": {
    "blocked-url": "https://third-party-test.glitch.me/check.svg?",
    "blockedURL": "https://third-party-test.glitch.me/check.svg?",
    "destination": "image",
    "disposition": "enforce",
    "type": "corp"
  },
  "type": "coep",
  "url": "https://cross-origin-isolation.glitch.me/?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"
}]

Beispiel für einen Bericht zur Kampagnenoptimierung

Ein Beispiel für eine COOP-Berichtsnutzlast, wenn ein Pop-up-Fenster isoliert geöffnet wird, sieht so aus:

[{
  "age": 7,
  "body": {
    "disposition": "enforce",
    "effectivePolicy": "same-origin",
    "nextResponseURL": "https://third-party-test.glitch.me/popup?report-only&coop=same-origin&",
    "type": "navigation-from-response"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/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, auf andere zuzugreifen (nur im Modus „Nur melden“), sendet COOP auch einen Bericht. Ein Bericht, wenn ein postMessage()-Versuch unternommen wird, sieht beispielsweise so aus:

[{
  "age": 51785,
  "body": {
    "columnNumber": 18,
    "disposition": "reporting",
    "effectivePolicy": "same-origin",
    "lineNumber": 83,
    "property": "postMessage",
    "sourceFile": "https://cross-origin-isolation.glitch.me/popup.js",
    "type": "access-from-coop-page-to-openee"
  },
  "type": "coop",
  "url": "https://cross-origin-isolation.glitch.me/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.glitch.me/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 isolierten, plattformübergreifenden Zustand zu versetzen. Sie können self.crossOriginIsolated prüfen, um festzustellen, ob sich eine Webseite in einem anbieterübergreifenden isolierten Zustand befindet.

Dieser Beitrag wird laufend aktualisiert, sobald neue Funktionen für diesen ursprungsübergreifenden isolierten Zustand verfügbar werden. Außerdem werden weitere Verbesserungen an den Entwicklertools bezüglich COOP und COEP vorgenommen.

Ressourcen