Cross-Origin Resource Policy (CORP)

Cross-Origin Resource Policy ist eine Richtlinie, die durch den Cross-Origin-Resource-Policy HTTP-Header festgelegt wird. Sie ermöglicht es Websites und Anwendungen, Schutz vor bestimmten Anfragen von anderen Ursprüngen (wie solchen, die mit Elementen wie <script> und <img> gestellt werden) zu aktivieren, um spekulative Seitenkanalangriffe wie Spectre sowie Cross-Site Script Inclusion-Angriffe zu mildern.

CORP ist eine zusätzliche Schutzschicht über die standardmäßige Same-Origin-Policy hinaus. Die Cross-Origin Resource Policy ergänzt das Cross-Origin Read Blocking (CORB), ein Mechanismus, der standardmäßig einige Cross-Origin-Lesezugriffe verhindert.

Hinweis: Die Richtlinie ist nur wirksam für no-cors Anfragen, die standardmäßig für CORS-safelisted Methoden/Header gestellt werden.

Da diese Richtlinie über einen Antwort-Header ausgedrückt wird, wird die tatsächliche Anfrage nicht verhindert – vielmehr verhindert der Browser, dass das Ergebnis durchsickert, indem der Antwortkörper entfernt wird.

Verwendung

Hinweis: Aufgrund eines Bugs in Chrome kann die Einstellung von Cross-Origin-Resource-Policy das Rendern von PDFs beeinträchtigen, was verhindert, dass Besucher weiter als die erste Seite einiger PDFs lesen können. Seien Sie vorsichtig bei der Verwendung dieses Headers in produktiven Umgebungen.

Webanwendungen setzen eine Cross-Origin Resource Policy über den Cross-Origin-Resource-Policy HTTP-Antwort-Header, der einen von drei Werten akzeptiert:

same-site

Nur Anfragen von derselben Site können die Ressource lesen.

Warnung: Dies ist weniger sicher als ein Ursprung. Der Algorithmus zur Überprüfung, ob zwei Ursprünge dieselbe Seite haben ist im HTML-Standard definiert und beinhaltet das Überprüfen der registrierbaren Domain.

same-origin

Nur Anfragen vom selben Ursprung (d.h. Schema + Host + Port) können die Ressource lesen.

cross-origin

Anfragen von jedem Ursprung (sowohl same-site als auch cross-site) können die Ressource lesen. Dies ist nützlich, wenn COEP verwendet wird (siehe unten).

http
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin

Während einer Cross-Origin-Resource-Policy-Prüfung, wenn der Header gesetzt ist, wird der Browser no-cors Anfragen von einem anderen Ursprung/Site ablehnen.

Beziehung zur Cross-Origin-Embedder-Policy (COEP)

Der Cross-Origin-Embedder-Policy HTTP-Antwort-Header kann, wenn er in einem Dokument verwendet wird, genutzt werden, um Unterressourcen zu erfordern, entweder denselben Ursprung wie das Dokument zu haben oder mit einem Cross-Origin-Resource-Policy HTTP-Antwort-Header zu kommen, um anzuzeigen, dass sie damit einverstanden sind, eingebettet zu werden. Dies ist der Grund, warum der cross-origin Wert existiert.

Geschichte

Das Konzept wurde ursprünglich 2012 als From-Origin vorgeschlagen, aber im zweiten Quartal 2018 wiederbelebt und in Safari und Chromium implementiert.

Anfang 2018 wurden zwei Seitenkanal-Hardware-Schwachstellen namens Meltdown und Spectre offengelegt. Diese Schwachstellen ermöglichten die Offenlegung sensibler Daten aufgrund einer Race Condition, die Teil der spekulativen Ausführungsfunktionalität war, die zur Leistungsverbesserung entwickelt wurde.

Als Reaktion darauf hat Chromium das Cross-Origin Read Blocking bereitgestellt, das automatisch bestimmte Ressourcen (mit Content-Type HTML, JSON und XML) vor Cross-Origin-Lesezugriffen schützt. Wenn die Anwendung keine no-sniff-Direktive bereitstellt, versucht Chromium, den Content-Type zu erraten und den Schutz dennoch anzuwenden.

Cross-Origin-Resource-Policy ist ein opt-in Antwort-Header, der jede Ressource schützen kann; es ist nicht erforderlich, dass Browser MIME-Typen sniffen.

Spezifikationen

Specification
Fetch
# cross-origin-resource-policy-header

Browser-Kompatibilität

Siehe auch