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.
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
oderrequire-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?
- Tracking-Problem in Firefox
- WebKit-Anfrage für Position: Kein Signal
- W3C TAG-Anfrage für Position: Ausstehend
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
- Website mit COOP und COEP „ursprungsübergreifend isoliert“ gestalten
- Warum Sie „ursprungsübergreifend“ für leistungsstarke Funktionen benötigen
- Leitfaden zum Aktivieren der ursprungsübergreifenden Isolierung
- SharedArrayBuffer-Updates in Android 88 und Chrome 92 für Computer
Foto von Martin Adams auf Unsplash