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.

Eiji Kitamura

Updates

• 21. Juni 2022: Bei aktivierter plattformübergreifender Isolation müssen auch Worker-Scripts mit Bedacht verwendet werden. Einige Erläuterungen hinzugefügt.
• 5. August 2021: Die JS Self-Profiling API wurde als eine der APIs erwähnt, für die eine plattformübergreifende Isolation erforderlich ist. Aufgrund der jüngeren Änderung der Ausrichtung 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 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: Einschränkungen für SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und Debugging-Funktionen wurden entfernt. Sie sind jetzt in Chrome 89 vollständig aktiviert. 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. Der freigegebene Array-Puffer ist in Chrome für Android ab Version 88 verfügbar.

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

Der Status „Ursprungsübergreifend isoliert“ verhindert auch Änderungen an 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 in einem 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 Browserkontextgruppe besteht aus mehreren Fenstern, die sich gegenseitig referenzieren können. Beispiel: ein Dokument der obersten Ebene und seine untergeordneten Dokumente, die über <iframe> eingebettet sind. Wenn eine Website (https://a.example) ein Pop-up-Fenster (https://b.example) öffnet, teilen sich das öffnende Fenster und das Pop-up-Fenster denselben Browserkontext. Daher haben sie über DOM-APIs wie window.opener Zugriff aufeinander.

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 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 fremdsprachigen 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.
• Bei iFrames gelten dieselben Prinzipien wie oben. Legen Sie Cross-Origin-Resource-Policy: cross-origin (oder same-site oder same-origin, je nach Kontext) 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. COEP-HTTP-Header „Nur Bericht“ verwenden, 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 Funktion 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

Die Property self.crossOriginIsolated gibt true zurück, wenn sich die Webseite in einem plattformübergreifenden isolierten Zustand befindet und alle Ressourcen und Fenster innerhalb derselben Browserkontextgruppe isoliert sind. Mit dieser API können Sie feststellen, ob Sie die Browserkontextgruppe 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. Verwenden Sie dazu den Bereich „Netzwerk“ in den DevTools. Wenn ein Problem mit 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 Pop-up-Fenster auch über den Bereich Anwendung ermitteln. Rufe links den Bereich „Frames“ auf und maximiere „oben“, um die Aufschlüsselung der Ressourcenstruktur aufzurufen.

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

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

Probleme mit 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 zum Empfangen 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()-Angriff versucht 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.

Wir aktualisieren diesen Beitrag, sobald neue Funktionen für diesen plattformübergreifenden, isolierten Zustand verfügbar sind und weitere Verbesserungen an den DevTools in Bezug auf COOP und COEP vorgenommen werden.

Ressourcen

• Warum Sie für leistungsstarke Funktionen „ursprungsübergreifend isoliert“ benötigen
• Leitfaden zum Aktivieren der ursprungsübergreifenden Isolierung
• Aktualisierungen für SharedArrayBuffer in Chrome 88 für Android und Chrome 92 für Computer
• Gesamte Arbeitsspeichernutzung Ihrer Webseite mit measureUserAgentSpecificMemory() beobachten