Cross-Origin-Embedder-Policy (COEP) header
Der HTTP Cross-Origin-Embedder-Policy
(COEP) Antwortheader konfiguriert die Richtlinie des aktuellen Dokuments für das Laden und Einbetten von Ressourcen aus verschiedenen Quellen.
Die Richtlinie, ob eine bestimmte Ressource plattformübergreifend eingebettet werden kann, kann für diese Ressource mithilfe des Cross-Origin-Resource-Policy
(CORP) Headers für einen no-cors
Abruf oder über CORS definiert werden. Wenn keine dieser Richtlinien festgelegt ist, können Ressourcen standardmäßig geladen oder in ein Dokument eingebettet werden, als hätten sie einen CORP-Wert von cross-site
.
Der Cross-Origin-Embedder-Policy
ermöglicht es Ihnen, zu verlangen, dass CORP- oder CORS-Header gesetzt werden, um plattformübergreifende Ressourcen in das aktuelle Dokument zu laden. Sie können die Richtlinie auch so einstellen, dass sie das Standardverhalten beibehält oder es erlaubt, die Ressourcen zu laden, jedoch ohne Anmeldedaten, die andernfalls gesendet würden. Die Richtlinie gilt für geladene Ressourcen und Ressourcen in <iframe>
s und verschachtelten Frames.
Hinweis:
Der Cross-Origin-Embedder-Policy
überschreibt oder beeinflusst nicht das Einbettverhalten für eine Ressource, für die CORP oder CORS festgelegt wurde. Wenn CORP eine Ressource darauf beschränkt, nur same-origin
eingebettet zu werden, wird sie unabhängig vom COEP-Wert nicht plattformübergreifend in eine Ressource geladen.
Header Typ | Antwortheader |
---|---|
Verbotener Antwortheader-Name | Nein |
Syntax
Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless
Direktiven
unsafe-none
-
Erlaubt dem Dokument, plattformübergreifende Ressourcen ohne ausdrückliche Erlaubnis durch das CORS-Protokoll oder den
Cross-Origin-Resource-Policy
Header zu laden. Dies ist der Standardwert. require-corp
-
Ein Dokument kann nur Ressourcen von derselben Quelle laden oder Ressourcen, die ausdrücklich als von einer anderen Quelle her ladbar markiert sind.
Das Laden plattformübergreifender Ressourcen wird von COEP blockiert, es sei denn:
- Die Ressource wird im
no-cors
Modus angefordert und die Antwort enthält einenCross-Origin-Resource-Policy
Header, der das Laden in der Dokumentquelle erlaubt. - Die Ressource wird im
cors
Modus angefordert und die Ressource unterstützt und ist durch CORS zugelassen. Dies kann zum Beispiel in HTML mit demcrossorigin
Attribut erfolgen oder in JavaScript durch eine Anfrage mit{mode="cors"}
.
- Die Ressource wird im
credentialless
-
Ein Dokument kann plattformübergreifende Ressourcen laden, die im
no-cors
Modus ohne ausdrückliche Erlaubnis über denCross-Origin-Resource-Policy
Header angefordert werden. In diesem Fall werden Anfragen ohne Anmeldedaten gesendet: Cookies werden bei der Anfrage weggelassen und in der Antwort ignoriert.Das plattformübergreifende Ladeverhalten für andere Anfragemodi ist das gleiche wie für
require-corp
. Zum Beispiel muss eine imcors
Modus angeforderte plattformübergreifende Ressource CORS unterstützen (und zugelassen sein).
Beispiele
Funktionen, die von einer isolierten Cross-Origin-Umgebung abhängen
Bestimmte Funktionen, wie der Zugriff auf SharedArrayBuffer
Objekte oder die Nutzung von Performance.now()
mit ungedrosselten Timern, sind nur verfügbar, wenn Ihr Dokument plattformsübergreifend isoliert ist.
Um diese Funktionen in einem Dokument nutzen zu können, müssen Sie den COEP-Header mit einem Wert von require-corp
oder credentialless
setzen und den Cross-Origin-Opener-Policy
Header auf same-origin
. Außerdem darf die Funktion nicht durch die Richtlinie Permissions-Policy: cross-origin-isolated
blockiert werden.
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
Sie können die Eigenschaften Window.crossOriginIsolated
und WorkerGlobalScope.crossOriginIsolated
verwenden, um zu überprüfen, ob die Funktionen im Fenster- und Worker-Kontext eingeschränkt sind:
const myWorker = new Worker("worker.js");
if (crossOriginIsolated) {
const buffer = new SharedArrayBuffer(16);
myWorker.postMessage(buffer);
} else {
const buffer = new ArrayBuffer(16);
myWorker.postMessage(buffer);
}
Vermeidung von COEP-Blockierungen mit CORS
Falls Sie COEP mit require-corp
aktivieren und eine plattformübergreifende Ressource einbetten möchten, die CORS unterstützt, müssen Sie ausdrücklich angeben, dass die Ressource im cors
Modus angefordert werden soll.
Um beispielsweise ein in HTML deklariertes Bild von einer Drittanbieter-Website abzurufen, das CORS unterstützt, können Sie das crossorigin
Attribut verwenden, damit es im cors
Modus angefordert wird:
<img src="https://thirdparty.com/img.png" crossorigin />
Sie können ähnlich das HTMLScriptElement.crossOrigin
Attribut verwenden oder mit { mode: 'cors' }
per JavaScript im CORS-Modus eine Datei anfordern.
Wenn CORS für einige Bilder nicht unterstützt wird, kann ein COEP-Wert von credentialless
als Alternative verwendet werden, um das Bild ohne ausdrückliche Zustimmung des plattformübergreifenden Servers zu laden, allerdings um den Preis, dass es ohne Cookies angefordert wird.
Spezifikationen
Specification |
---|
HTML # coep |
Browser-Kompatibilität
Siehe auch
Cross-Origin-Opener-Policy
Window.crossOriginIsolated
undWorkerGlobalScope.crossOriginIsolated
- Cross Origin Opener Policy in Why you need "cross-origin isolated" for powerful features auf web.dev (2020)
- COOP und COEP erklärt: Artur Janc, Charlie Reis, Anne van Kesteren (2020)