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

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

Eiji Kitamura

Updates

  • 21. Juni 2022: Auch Worker-Scripts müssen berücksichtigt werden, wenn die ursprungsübergreifende Isolation aktiviert ist. Einige Erläuterungen hinzugefügt.
  • 5. August 2021: Die JS Self-Profiling API wurde als eine der APIs genannt, für die die ursprungsübergreifende Isolation erforderlich ist. Aufgrund der jüngsten Ä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 SharedArrayBuffer-Nutzung auf Websites, die nicht ursprungsübergreifend isoliert sind, auf Chrome M92 zu verschieben.
  • 16. April 2021: Es wurden Hinweise zu einem neuen COEP-Modus ohne Anmeldedaten und COOP-same-origin-allow-popups als gelockerte 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 Funktionen sind jetzt in Chrome 89 vollständig aktiviert. Es wurden die demnächst verfügbaren Funktionen performance.now() und performance.timeOrigin hinzugefügt, die eine höhere Genauigkeit bieten.
  • 19. Februar 2021: Hinweis zur Funktionsrichtlinieallow="cross-origin-isolated" und zur Debugging-Funktionalität in den Entwicklertools 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() wird nicht mehr als Origin Trial angeboten und ist in Chrome 89 standardmäßig aktiviert. Shared Array Buffer ist in Android Chrome ab Chrome 88 verfügbar.

Einige Web-APIs erhöhen das Risiko von Side-Channel-Angriffen wie Spectre. Um dieses Risiko zu minimieren, bieten Browser eine opt-in-basierte isolierte Umgebung namens „ursprungsübergreifende Isolierung“ an. In einem cross-origin-isolierten Status kann die Webseite privilegierte Funktionen nutzen, darunter:

API Beschreibung
SharedArrayBuffer Erforderlich für WebAssembly-Threads. Diese Funktion ist ab Android Chrome 88 verfügbar. Die Desktopversion ist derzeit standardmäßig mit der Website-Isolierung aktiviert, 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 höher begrenzt ist. Bei der ursprungsübergreifenden Isolation kann die Auflösung 5 Mikrosekunden oder höher sein.
Funktionen, die im Status „ursprungsübergreifend isoliert“ verfügbar sind.

Der Status „ursprungsübergreifend isoliert“ verhindert auch Änderungen an document.domain. (Die Möglichkeit, document.domain zu ändern, ermöglicht die Kommunikation zwischen SameSite-Dokumenten und wurde als Sicherheitslücke in der Same-Origin-Policy betrachtet.)

Wenn Sie die ursprungsübergreifende Isolierung aktivieren möchten, müssen Sie die folgenden HTTP-Header für das 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 optimiert wurden. Außerdem wird verhindert, dass ursprungsübergreifende Fenster direkt mit Ihrem Dokument interagieren. Das bedeutet auch, dass für das Laden dieser Ressourcen ursprungsübergreifend eine Einwilligung erforderlich ist.

Sie können feststellen, ob sich eine Webseite in einem Cross-Origin-Isolated-Zustand befindet, indem Sie self.crossOriginIsolated untersuchen.

In diesem Artikel wird beschrieben, wie Sie diese neuen Headern verwenden. In einem Folgeartikel werde ich mehr Hintergrundinformationen und Kontext liefern.

COOP und COEP bereitstellen, um Ihre Website cross-origin-isolated zu machen

COOP und COEP einbinden

1. Legen Sie den Cross-Origin-Opener-Policy: same-origin-Header für das Dokument der obersten Ebene fest.

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 Browsing-Kontextgruppe, sofern sie nicht denselben Ursprung mit derselben COOP-Einstellung haben. 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 über <iframe> eingebettet sind. Wenn auf einer Website (https://a.example) ein Pop-up-Fenster (https://b.example) geöffnet wird, haben das Fenster, in dem die Website geöffnet ist, und das Pop-up-Fenster denselben Browserkontext. Daher haben sie über DOM-APIs wie window.opener Zugriff aufeinander.

Browsing Context Group

Sie können über die Entwicklertools prüfen, ob sich das Fenster, das das neue Fenster öffnet, und das neue Fenster in separaten Browserkontextgruppen befinden.

2. Prüfen, ob CORP oder CORS für Ressourcen 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, das Aktivieren von COEP, erforderlich.

So gehen Sie je nach Art der Ressource vor:

  • Wenn die Ressource nur von derselben Quelle 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 Cross-Origin-Resource-Policy: same-site-Header fest.
  • Wenn die Ressource von ursprungsübergreifenden Quellen geladen wird, die Sie kontrollieren, legen Sie den Header Cross-Origin-Resource-Policy: cross-origin nach Möglichkeit 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 Eigentümer der Ressource, entweder CORS oder CORP zu unterstützen.
  • Bei iFrames gelten dieselben Grundsätze wie oben. Legen Sie Cross-Origin-Resource-Policy: cross-origin (oder same-site, same-origin, je nach Kontext) fest.
  • Skripts, die mit einem WebWorker geladen werden, müssen vom selben Ursprung bereitgestellt werden. Daher sind keine CORP- oder CORS-Header erforderlich.
  • Bei einem Dokument oder Worker, der mit COEP: require-corp bereitgestellt wird, muss für untergeordnete Ressourcen, die ohne CORS geladen werden, der Header Cross-Origin-Resource-Policy: cross-origin festgelegt werden, um das Einbetten zu aktivieren. Das gilt beispielsweise für <script>, importScripts, <link>, <video> und <iframe>.

3. Eingebettete Ressourcen mit dem COEP-HTTP-Header „report-only“ 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 eingebettete Inhalte zu blockieren.

Wenden Sie 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

Wenn Sie bestätigt haben, dass alles funktioniert und alle Ressourcen erfolgreich geladen werden können, ersetzen Sie den Cross-Origin-Embedder-Policy-Report-Only-Header durch den Cross-Origin-Embedder-Policy-Header mit demselben Wert für alle Dokumente, einschließlich der Dokumente, die über iFrames und Worker-Scripts eingebettet sind.

Prüfen, ob die Isolation mit self.crossOriginIsolated 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 in derselben Browserkontextgruppe isoliert sind. Mit dieser API können Sie feststellen, ob Sie die Gruppe des Browserkontexts erfolgreich isoliert und Zugriff auf leistungsstarke Funktionen wie performance.measureUserAgentSpecificMemory() erhalten haben.

Probleme mit Chrome-Entwicklertools beheben

Bei Ressourcen, die auf dem Bildschirm gerendert werden, z. B. Bilder, 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 Wirkung haben, z. B. Scripts oder Styles, bleiben COEP-Probleme jedoch möglicherweise unbemerkt. Verwenden Sie dazu den Bereich „Netzwerk“ 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 aufzurufen.

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 Anwendungsfeld ermitteln. Gehen Sie links zum Bereich „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.

Chrome-Entwicklertools – iframe-Untersuchung

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

Chrome-Entwicklertools-Pop-up-Fenster-Inspector

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 verschiedene Anwendungsfälle, 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

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 COOP-Bericht

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

[{
  "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 Gruppen von Browserkontexten versuchen, aufeinander zuzugreifen (nur im Modus „report-only“), wird auch ein COOP-Bericht gesendet. Ein Bericht, wenn postMessage() 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

Mit einer Kombination aus COOP- und COEP-HTTP-Headern können Sie eine Webseite in einen speziellen, ursprungsübergreifend isolierten Status versetzen. Sie können self.crossOriginIsolated untersuchen, um festzustellen, ob sich eine Webseite in einem cross-origin-isolierten Zustand befindet.

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

Ressourcen