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

Mit COOP und COEP kannst du eine ursprungsübergreifende isolierte Umgebung einrichten und leistungsstarke Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und einen Timer mit hoher Präzision aktivieren.

Eiji Kitamura

Updates

  • 21. Juni 2022: Auch bei aktivierter ursprungsübergreifender Isolierung müssen Worker-Skripts berücksichtigt werden. Es wurden 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 kürzlich erfolgten Richtungsänderung wurde sie jedoch entfernt.
  • 6. Mai 2021: Auf Grundlage des Feedbacks und der gemeldeten Probleme haben wir beschlossen, den Zeitplan für die SharedArrayBuffer-Nutzung auf keinen ursprungsübergreifenden Websites, die in Chrome M92 eingeschränkt werden sollen, anzupassen.
  • 16. April 2021: Es wurden Hinweise zu einem neuen COEP-Modus ohne Anmeldedaten und COOP same-origin-allow-popups als lockere Bedingung für die ursprungsübergreifende Isolierung hinzugefügt.
  • 5. März 2021: Einschränkungen für SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und Debugging-Funktionen wurden entfernt, die in Chrome 89 jetzt vollständig aktiviert sind. Neue Funktionen wie performance.now() und performance.timeOrigin, die eine höhere Genauigkeit bieten, wurden hinzugefügt.
  • 19. Februar 2021: Wir haben einen Hinweis zur Funktionsrichtlinie allow="cross-origin-isolated" und zu den Fehlerbehebungsfunktionen in den Entwicklertools hinzugefügt.
  • 15. Oktober 2020: self.crossOriginIsolated ist über Chrome 87 verfügbar. Daher ist document.domain unveränderlich, wenn self.crossOriginIsolated true zurückgibt. performance.measureUserAgentSpecificMemory() beendet den Ursprungstest und ist in Chrome 89 standardmäßig aktiviert. Ein geteilter Array-Zwischenspeicher ist in Android-Chrome ab Chrome 88 verfügbar.

Einige Web-APIs erhöhen das Risiko von Seitenkanalangriffen wie Spectre. Um dieses Risiko zu minimieren, bieten Browser eine auf Opt-in-basierte isolierte Umgebung, die „ursprungsübergreifend isoliert“ genannt wird. Im ursprungsübergreifenden Status kann die Webseite privilegierte Funktionen verwenden, darunter:

API Beschreibung
SharedArrayBuffer Erforderlich für WebAssembly-Threads. Diese Funktion ist ab Android Chrome 88 verfügbar. Die Desktopversion ist derzeit standardmäßig mithilfe der Website-Isolierung aktiviert, erfordert jedoch den ursprungsübergreifenden Status und wird in Chrome 92 standardmäßig deaktiviert.
performance.measureUserAgentSpecificMemory() Verfügbar ab Chrome 89.
performance.now(), performance.timeOrigin Derzeit in vielen Browsern mit einer Auflösung von mindestens 100 Mikrosekunden verfügbar. Mit ursprungsübergreifender Isolierung kann die Auflösung 5 Mikrosekunden oder mehr betragen.
Funktionen, die hinter dem ursprungsübergreifenden Status verfügbar sein werden.

Der ursprungsübergreifende isolierte Zustand 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 Sicherheitslücke in der Richtlinie für denselben Ursprung erachtet.

Um den ursprungsübergreifenden Status zu aktivieren, musst du 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, für die das Laden von ursprungsübergreifenden Dokumenten nicht aktiviert wurde, und verhindern, dass ursprungsübergreifende Fenster direkt mit Ihrem Dokument interagieren. Das bedeutet auch, dass diese Ressourcen, die ursprungsübergreifend geladen werden, Opt-ins erfordern.

Du kannst feststellen, ob eine Webseite ursprungsübergreifend isoliert ist. Dazu prüfst du self.crossOriginIsolated.

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

Mit COOP und COEP Ihre Website ursprungsübergreifend isolieren

COOP und COEP einbinden

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

Wenn Sie COOP: same-origin für ein Dokument auf oberster Ebene aktivieren, erhalten Fenster mit demselben Ursprung und aus dem Dokument geöffnete Fenster eine separate Suchkontextgruppe, es sei denn, sie befinden sich am selben Ursprung mit derselben COOP-Einstellung. Daher wird die Isolation für geöffnete Fenster erzwungen und die gegenseitige Kommunikation zwischen beiden Fenstern wird deaktiviert.

Eine Suchkontextgruppe ist ein Satz von Fenstern, die aufeinander verweisen 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, haben das Öffnen-Fenster und das Pop-up-Fenster denselben Browser-Kontext, sodass sie über DOM APIs wie window.opener aufeinander zugreifen können.

Kontextgruppe durchsuchen

Sie können prüfen, ob sich das Öffnen und das Öffnen des Fensters in separaten Suchkontextgruppen aus den Entwicklertools befinden.

2. Achten Sie darauf, dass CORP oder CORS für Ressourcen aktiviert ist

Alle Ressourcen auf der Seite müssen 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 nur aus demselben Ursprung geladen werden soll, legen Sie den Cross-Origin-Resource-Policy: same-origin-Header fest.
  • Wenn die Ressource nur von derselben Website, aber ursprungsübergreifend geladen werden soll, lege den Cross-Origin-Resource-Policy: same-site-Header fest.
  • Wenn die Ressource von ursprungsübergreifenden, von Ihnen kontrollierten Quellen geladen wird, legen Sie 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 ladenden HTML-Tag, 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.
  • Gehen Sie bei iFrames wie oben beschrieben vor und legen Sie den Cross-Origin-Resource-Policy: cross-origin (oder same-site, same-origin) fest, je nach Kontext.
  • Skripts, die mit einem WebWorker geladen werden, müssen vom selben Ursprung bereitgestellt werden, sodass Sie keine CORP- oder CORS-Header benötigen.
  • Für ein Dokument oder einen Worker, das mit COEP: require-corp bereitgestellt wird, müssen ursprungsübergreifende Unterressourcen, die ohne CORS geladen werden, den Cross-Origin-Resource-Policy: cross-origin-Header festlegen, um die Einbettung zu aktivieren. Dies gilt beispielsweise für <script>, importScripts, <link>, <video>, <iframe> usw.

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

Bevor Sie COEP vollständig aktivieren, können Sie einen Probelauf ausführen. Dazu verwenden Sie den Header Cross-Origin-Embedder-Policy-Report-Only, um zu prüfen, ob die Richtlinie tatsächlich funktioniert. Sie erhalten Berichte, ohne eingebettete Inhalte zu blockieren.

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

4. COEP aktivieren

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

Bestimmen Sie, ob die Isolierung mit self.crossOriginIsolated erfolgreich war

Das Attribut self.crossOriginIsolated gibt true zurück, wenn die Webseite ursprungsübergreifend isoliert ist und alle Ressourcen und Fenster innerhalb derselben Browserkontextgruppe isoliert sind. Mit dieser API können Sie feststellen, ob Sie die Browser-Kontextgruppe 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. Bilder, können COEP-Probleme relativ einfach erkannt werden, da die Anfrage blockiert wird und auf der Seite ein fehlendes Bild angezeigt wird. Bei Ressourcen wie Skripts oder Stilen, die unbedingt keine visuelle Wirkung haben, bleiben COEP-Probleme jedoch möglicherweise unbemerkt. Nutzen Sie hierfür in den Entwicklertools das Steuerfeld „Netzwerk“. Bei einem Problem mit COEP sollte in der Spalte Status (blocked:NotSameOriginAfterDefaultedToSameOriginByCoep) angezeigt werden.

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

Sie können dann auf den Eintrag klicken, um weitere Details zu sehen.

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

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

Du kannst den Status des iFrames prüfen, z. B. die Verfügbarkeit von SharedArrayBuffer.

iFrame-Inspector in den Chrome-Entwicklertools

Du kannst auch den Status der Pop-up-Fenster prüfen, z. B. ob sie ursprungsübergreifend isoliert ist.

Pop-up-Fensterprüfer in den Chrome-Entwicklertools

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 immer dann 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 verschiedene Zwecke, unter anderem für 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

Hier ein Beispiel für eine Nutzlast für einen COEP-Bericht, wenn eine ursprungsübergreifende Ressource blockiert wird:

[{
  "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"
}]

COOP-Beispielbericht

Ein Beispiel für eine Nutzlast für einen COOP-Bericht, wenn ein isoliertes Pop-up-Fenster 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, aufeinander zuzugreifen (nur im Modus „Nur Bericht“), sendet COOP auch einen Bericht. Ein Bericht mit dem Versuch postMessage() würde beispielsweise so aussehen:

[{
  "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

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

Wir halten diesen Beitrag immer auf dem Laufenden, wenn in diesem ursprungsübergreifenden Status neue Funktionen zur Verfügung gestellt und weitere Verbesserungen an den Entwicklertools COOP und COEP vorgenommen werden.

Ressourcen