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 Funktionenperformance.now()
undperformance.timeOrigin
hinzugefügt, die eine höhere Präzision bieten. - 19. Februar 2021: Hinweis zur Funktionsweise von DevTools im Hinblick auf die Richtlinie zu Funktionen
allow="cross-origin-isolated"
hinzugefügt. - 15. Oktober 2020:
self.crossOriginIsolated
ist ab Chrome 87 verfügbar. Daher istdocument.domain
unveränderlich, wennself.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. |
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.
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.
- Verwende das
- Folgen Sie bei iFrames denselben Prinzipien wie oben und legen Sie je nach Kontext
Cross-Origin-Resource-Policy: cross-origin
(odersame-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, dieCross-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.
Klicken Sie dann auf den Eintrag, um weitere Details zu sehen.
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
.
Sie können auch den Status der Pop-up-Fenster prüfen, z. B. ob sie plattformübergreifend isoliert sind.
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
- 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