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.
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 wieperformance.now()
undperformance.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 istdocument.domain
unveränderlich, wennself.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. |
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.
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.
- Verwenden Sie das Attribut
- Gehen Sie bei iFrames wie oben beschrieben vor und legen Sie den
Cross-Origin-Resource-Policy: cross-origin
(odersame-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, denCross-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.
Sie können dann auf den Eintrag klicken, um weitere Details zu sehen.
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
.
Du kannst auch den Status der Pop-up-Fenster prüfen, z. B. ob sie ursprungsübergreifend isoliert ist.
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
- Warum Sie „ursprungsübergreifend“ für leistungsstarke Funktionen benötigen
- Leitfaden zum Aktivieren der ursprungsübergreifenden Isolierung
- SharedArrayBuffer-Updates in Android Chrome 88 und Chrome 92 für Computer
- Mit
measureUserAgentSpecificMemory()
die gesamte Arbeitsspeichernutzung Ihrer Webseite im Blick behalten