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

Von Drittanbietern bereitgestellte ursprungsübergreifende Ressourcen enthalten oft keine geeigneten CORP-Header. Wenn sie ohne Anmeldedaten angefordert werden können, können Sie jetzt die ursprungsübergreifende Isolierung aktivieren, indem Sie sie als solche kennzeichnen.

Eiji Kitamura

Wir haben den neuen COEP-Wert credentialless (Cross-Origin Embedder Policy) veröffentlicht, mit dem der Browser ursprungsübergreifende Ressourcen laden kann, die nicht die Cross-Origin Resource Policy (CORP) verwenden. Dazu wird eine Anfrage ohne Anmeldedaten wie Cookies gesendet. So können Entwickler die ursprungsübergreifende Isolierung leichter einführen.

Warum wir die ursprungsübergreifende Isolierung benötigen

Einige Web-APIs erhöhen das Risiko von Seitenkanalangriffen wie Spectre. Um dieses Risiko zu verringern, bieten Browser eine isolierte, auf Opt-in-Basis basierende Umgebung, die als ursprungsübergreifende Isolierung bezeichnet wird. Im ursprungsübergreifenden isolierten Status kann die Webseite privilegierte Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und hochpräzise Timer mit besserer Auflösung verwenden. Dabei wird der Ursprung von anderen isoliert, sofern sie 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

In einem ursprungsübergreifenden Status müssen alle ursprungsübergreifenden Ressourcen mit CORS bereitgestellt werden oder zum Laden einen Cross-Origin-Resource-Policy-Header festlegen.

Herausforderungen beim Aktivieren der ursprungsübergreifenden Isolierung

Die ursprungsübergreifende Isolierung erhöht die Sicherheit von Webseiten und bietet die Möglichkeit, leistungsstarke Funktionen zu aktivieren. Ihre Bereitstellung kann jedoch schwierig sein. Eine der größten Herausforderungen besteht darin, CORS oder CORP für alle ursprungsübergreifenden Ressourcen zu aktivieren. Ressourcen ohne diese Header werden vom Browser nicht auf einer ursprungsübergreifenden, isolierten Seite geladen.

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

Aber was ist, wenn wir wissen, dass die Ressource sicher genug ist, um geladen zu werden? Die einzigen Ressourcen, die gefährdet sind, sind solche, die mit Anmeldedaten angefordert werden, da sie möglicherweise vertrauliche Informationen enthalten, die der Angreifer nicht selbst laden kann. Dies bedeutet, dass Ressourcen, die ohne Anmeldedaten angefordert werden können, öffentlich verfügbar und sicher geladen werden können.

credentialless zur Rettung

Hier kommt COEP: credentialless ins Spiel. credentialless ist ein neuer Wert für den Cross-Origin-Embedder-Policy-Header. Ähnlich wie bei require-corp kann die ursprungsübergreifende Isolierung aktiviert werden. Allerdings ist für ursprungsübergreifende No-CO-Anfragen kein CORP:cross-origin-Header erforderlich, sondern werden ohne Anmeldedaten (z. B. Cookies) gesendet.

Du kannst die ursprungsübergreifende Isolierung alternativ mit den folgenden beiden Headern aktivieren:

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

Das bedeutet, dass der angeforderte ursprungsübergreifende Server nicht mit einer vertraulichen Ressource antworten kann und der Anforderer 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 Header-Optionen ausprobieren: https://cross-origin-isolation.glitch.me

Häufig gestellte Fragen

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

Absolut, allerdings auf Kosten eines Umschaltens des Anfragemodus, damit eine CORS-Prüfung der Antwort erforderlich ist. Hängen Sie für HTML-Tags wie <audio>, <img>, <link>, <script> und <video> einfach crossorigin="use-credentials" explizit an, um den Browser zu informieren, dass Anfragen mit Anmeldedaten gesendet werden sollen.

Selbst wenn beispielsweise ein Dokument in https://www.example.com den Header Cross-Origin-Embedder-Policy: credentialless 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.

Angegebene COEP: credentialless. Wie ist COEP: require-corp weiterhin für meine Website nützlich?

COEP: require-corp erfordert nicht, den Anfragemodus manuell auf CORS umzustellen, wenn Cookies für einige ursprungsübergreifende Unterressourcen benötigt werden.

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

Nein. Für das Laden von ursprungsübergreifenden iFrames in einer credentialless-Umgebung sind immer noch dieselben Bedingungen erforderlich wie für require-corp. iFrame-Dokumente müssen mit zwei Headern bereitgestellt werden:

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

Die gute Nachricht ist, dass es derzeit diskutiert wird, wie das Laden von ursprungsübergreifenden iFrames ohne diese Header zulässig ist, wenn iFrames crossorigin="anonymous" zur Verfügung gestellt werden. Dadurch können ursprungsübergreifende iFrames ohne Header, aber ohne Anmeldedaten geladen werden.

Wird diese Funktion auch in anderen Browsern eingeführt?

Nächste Schritte

Es gibt zwei weitere Updates, um andere Probleme im Zusammenhang mit der ursprungsübergreifenden Isolierung zu verringern:

Diejenigen, die sich aufgrund der oben genannten Hindernisse für den Ursprungstest von Chrome registriert haben, um die Änderung „SharedArrayBuffer“ zu verlängern, fragen sich vielleicht, wann der Test beendet wird. Ursprünglich hatten wir angekündigt, dass es in Chrome 96 eingestellt wird. Wir haben uns aber entschieden, dies auf Chrome 106 zu verschieben.

Ressourcen

Foto von Martin Adams auf Unsplash