iFrame ohne Anmeldedaten: Einfache Einbettung von iFrames in COEP-Umgebungen

Arthur Sonzogni
Arthur Sonzogni

Entwickler, die COEP verwenden, können jetzt Drittanbieter-iFrames einbetten, die nicht selbst COEP verwenden.

iFrame Credentialless ist ab Chrome-Version 110 standardmäßig aktiviert. Sie dient als Lösung für die häufigsten Beschwerden von Entwicklern, die mit Cross-Origin-Embedder-Policy (COEP) arbeiten. Das Einbetten von Drittanbieter-iFrames ohne COEP ist möglich.

Warum wir COEP brauchen

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 namens ursprungsübergreifende Isolierung. Dazu muss COEP bereitgestellt werden. Dank der ursprungsübergreifenden Isolierung können Websites privilegierte Funktionen wie SharedArrayBuffer, performance.measureUserAgentSpecificMemory() und präzise Timer mit besserer Auflösung nutzen.

Websites müssen die folgenden HTTP-Header senden, um die ursprungsübergreifende Isolierung zu aktivieren:

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

COEP:credentialless kann auch als Alternative zu require-corp verwendet werden. Weitere Informationen finden Sie in der Dokumentation.

Herausforderungen bei der Umsetzung von COEP

Die ursprungsübergreifende Isolierung verbessert die Sicherheit von Webseiten und ermöglicht die Aktivierung leistungsstarker Funktionen. Die Implementierung von COEP kann jedoch schwierig sein. Eine der größten Herausforderungen besteht darin, dass für alle ursprungsübergreifenden iFrames COEP und CORP bereitgestellt werden müssen. iFrames ohne diese Header werden vom Browser nicht geladen.

iFrame Credentialless

Wir führen <iframe credentialless> ein, um Drittanbieter-iFrames einzubetten, die kein COEP festlegen. Wenn Sie dem <iframe>-Element das Attribut credentialless hinzufügen, wird der iFrame aus einem anderen, leeren Kontext geladen. Insbesondere wird sie ohne Cookies geladen. Dadurch kann die COEP-Einschränkung aufgehoben werden.

Beispiel:

<iframe credentialless src="https://example.com">

Dieser iFrame wird in einem neuen sitzungsspezifischen Kontext erstellt und hat keinen Zugriff auf die Cookies, die mit der Top-Level-Website verknüpft sind. Stattdessen beginnt sie mit einer leeren Keksdose. Ebenso laden und speichern Speicher-APIs wie LocalStorage, CacheStorage, IndexedDB usw. Daten in der neuen sitzungsspezifischen Partition. Die Partition bezieht sich sowohl auf das aktuelle Dokument der obersten Ebene als auch auf den Ursprung des iFrame. Der gesamte Speicherplatz wird gelöscht, sobald das Dokument auf oberster Ebene entladen wurde.

iFrames ohne Anmeldedaten unterliegen nicht den COEP-Einbettungsregeln. Sie sind weiterhin sicher: Da sie jedes Mal aus einem neuen leeren Kontext geladen werden, sollten sie keine personalisierten Daten enthalten, worauf die Angreifer abzielen. Wenn ein iFrame nur öffentliche Daten enthält, ist er für einen Angreifer nicht wertvoll.

Demo

Sie können sich eine Demo eines iFrames ohne Anmeldedaten ansehen.

FAQ

Wird diese Funktion auch in anderen Browsern verfügbar sein?

Ist ein <iframe> in einem <iframe credentialless> ohne Anmeldedaten verschachtelt?

Ja. Sie wird übernommen. Wenn ein iFrame keine Anmeldedaten mehr hat, gilt dies für alle iFrames in der gesamten Unterstruktur, auch ohne das Attribut credentialless.

Werden Pop-ups auch ohne Anmeldedaten für <iframe credentialless> erstellt?

Pop-ups werden so geöffnet, als wäre noopener festgelegt. Sie werden in einem neuen regulären Kontext auf oberster Ebene erstellt und haben keine Anmeldedaten. Sie können nicht mit dem iFrame ohne Anmeldedaten kommunizieren.

Woran erkenne ich, dass das Dokument in einen iFrame ohne Anmeldedaten eingebettet wurde?

window.credentialless ist in einem iFrame ohne Anmeldedaten „true“, andernfalls „false“. Der Wert lautet undefined in einem Webbrowser, der <iframe credentialless> nicht unterstützt.

Ressourcen