Ursprungsübergreifende Ressourcen ohne CORP-Header mit COEP: ohne Anmeldedaten laden

Von Drittanbietern bereitgestellte plattformübergreifende Ressourcen enthalten häufig keine geeigneten CORP-Header. Wenn sie ohne Anmeldedaten angefordert werden können, können Sie jetzt die plattformübergreifende Isolation aktivieren, indem Sie sie entsprechend kennzeichnen.

Eiji Kitamura

Wir haben den neuen Wert credentialless für die COEP-Richtlinie (Cross-Origin Embedder Policy) eingeführt. Damit kann der Browser Ressourcen unterschiedlicher Herkunft laden, die die CORP-Richtlinie (Cross-Origin Resource Policy) nicht verwenden. Dazu wird eine Anfrage ohne Anmeldedaten wie Cookies gesendet. Das erleichtert Entwicklern die Einführung der plattformübergreifenden Isolation.

Warum ist die ursprungsübergreifende Isolierung erforderlich?

Einige Web-APIs erhöhen das Risiko von Seitenkanalangriffen wie Spectre. Um dieses Risiko zu minimieren, bieten Browser eine isolierte Umgebung mit Opt-in-Funktion namens Cross-Origin-Isolation. Bei einem plattformübergreifenden isolierten Zustand kann die Webseite privilegierte Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und hochpräzise Timer mit besserer Auflösung verwenden und den Ursprung von anderen isolieren, sofern diese nicht aktiviert sind.

Die Webseite muss zwei HTTP-Header senden, um die ursprungsübergreifende Isolierung zu aktivieren:

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Bei einem isolierten Ursprung müssen alle plattformübergreifenden Ressourcen mit CORS bereitgestellt oder ein Cross-Origin-Resource-Policy-Header zum Laden festgelegt werden.

Herausforderungen bei der Aktivierung der ursprungsübergreifenden Isolierung

Die plattformübergreifende Isolation bietet zwar eine bessere Sicherheit für Webseiten und die Möglichkeit, leistungsstarke Funktionen zu aktivieren, die Implementierung kann jedoch schwierig sein. Eine der größten Herausforderungen besteht darin, CORS oder CORP für alle plattformübergreifenden Ressourcen zu aktivieren. Ressourcen ohne diese Header werden vom Browser auf einer seitenübergreifenden, isolierten Seite nicht geladen.

Diese plattformübergreifenden Ressourcen werden in der Regel von Drittanbietern bereitgestellt, für die es möglicherweise nicht einfach ist, die erforderlichen Header hinzuzufügen.

Aber was ist, wenn wir wissen, dass die Ressource sicher genug zum Laden ist? Tatsächlich sind nur Ressourcen gefährdet, die mit Anmeldedaten angefordert werden, da sie potenziell vertrauliche Informationen enthalten, die der Angreifer nicht selbst laden kann. Das bedeutet, dass Ressourcen, die ohne Anmeldedaten angefordert werden können, öffentlich verfügbar und sicher zu laden sind.

credentialless als Retter in der Not

Hier kommt COEP: credentialless ins Spiel. credentialless ist ein neuer Wert für den Cross-Origin-Embedder-Policy-Header. Ähnlich wie require-corp kann es die ursprungsübergreifende Isolierung aktivieren. Anstatt dass für ursprungsübergreifende Anfragen ohne CORS ein CORP:cross-origin-Header erforderlich ist, werden sie stattdessen ohne Anmeldedaten (z. B. Cookies) gesendet.

Alternativ können Sie die ursprungsübergreifende Isolierung mit den folgenden beiden Headern aktivieren:

Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin

Das bedeutet, dass der angeforderte serverübergreifende Server nicht mit einer sensiblen Ressource antworten kann und der Anfragende immer davon ausgehen kann, dass die Antwort nur öffentlich verfügbare Informationen enthält.

Dies entspricht auch dem Plan der Browser, Drittanbieter-Cookies schrittweise einzustellen.

Demo

In dieser Demo kannst du verschiedene Headeroptionen ausprobieren: https://cross-origin-isolation.glitch.me

FAQ

Kann ich eine Anfrage mit Anmeldedaten in einer credentialless-Umgebung senden?

Ja, aber dann muss der Modus der Anfrage so geändert werden, dass eine CORS-Prüfung der Antwort erforderlich ist. Fügen Sie HTML-Tags wie <audio>, <img>, <link>, <script> und <video> einfach crossorigin="use-credentials" hinzu, um den Browser anzuweisen, Anfragen mit Anmeldedaten zu senden.

Auch wenn ein Dokument unter https://www.example.com den Cross-Origin-Embedder-Policy: credentialless-Header hat, sendet <img src="https://images.example.com/avatar.png" crossorigin="use-credentials"> eine Anfrage mit Anmeldedaten.

Für die fetch() API kann request.mode = 'cors' verwendet werden.

Ich habe COEP: credentialless angegeben. Inwiefern ist COEP: require-corp dann noch für meine Website nützlich?

Bei COEP: require-corp müssen Sie den Anfragemodus nicht manuell zu CORS wechseln, wenn für einige untergeordnete Ressourcen mit unterschiedlichen Ursprüngen Cookies erforderlich sind.

Kann ich in einer credentialless-Umgebung auch ursprungsübergreifende iFrames ohne spezielle Header laden?

Nein. Für das Laden von iframes mit unterschiedlichen Ursprüngen in einer credentialless-Umgebung gelten weiterhin dieselben Bedingungen wie für require-corp. iFrame-Dokumente müssen mit zwei Headern ausgeliefert werden:

  • Cross-Origin-Embedder-Policy: credentialless oder require-corp
  • Cross-Origin-Resource-Policy: cross-origin

Die gute Nachricht ist, dass derzeit diskutiert wird, ob iframes ohne diese Header geladen werden dürfen, indem iframes crossorigin="anonymous" zugewiesen werden. So können ursprungsübergreifende iFrames ohne Header, aber ohne Anmeldedaten geladen werden.

Wird diese Funktion auch in anderen Browsern übernommen?

Nächste Schritte

Es sind zwei weitere Updates geplant, um andere Herausforderungen im Zusammenhang mit der ursprungsübergreifenden Isolierung zu beheben:

Nutzer, die sich aufgrund der oben genannten Probleme für den Chrome-Ursprungstest zur Verlängerung der SharedArrayBuffer-Änderung registriert haben, fragen sich möglicherweise, wann dieser Test beendet wird. Ursprünglich hatten wir angekündigt, dass die Unterstützung in Chrome 96 eingestellt wird. Wir haben uns jedoch entschieden, dies auf Chrome 106 zu verschieben.

Ressourcen

Foto von Martin Adams auf Unsplash