Cross-Origin Resource Policy (CORP)

Die 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, sich gegen bestimmte Anfragen von anderen Ursprüngen (wie die, die durch Elemente wie <script> und <img> ausgegeben werden) zu schützen, 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. Cross-Origin Resource Policy ergänzt Cross-Origin Read Blocking (CORB), einen Mechanismus, der standardmäßig einige Cross-Origin-Lesevorgänge verhindert.

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

Da diese Richtlinie über einen Response Header ausgedrückt wird, wird die tatsächliche Anfrage nicht verhindert. Vielmehr verhindert der Browser, dass das Ergebnis durch das Entfernen des Antworttextes offengelegt wird.

Verwendung

Hinweis: Aufgrund eines Bugs in Chrome kann das Setzen von Cross-Origin-Resource-Policy das Rendern von PDFs beeinträchtigen, wodurch Besucher daran gehindert werden, über die erste Seite hinaus zu lesen. Seien Sie vorsichtig bei der Verwendung dieses Headers in einer Produktionsumgebung.

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

same-site

Nur Anfragen von der gleichen Site können die Ressource lesen.

Warnung: Dies ist weniger sicher als ein Origin. Der Algorithmus zur Überprüfung, ob zwei Ursprünge dieselbe Site sind ist im HTML-Standard definiert und beinhaltet die Überprüfung der registrierbaren Domain.

same-origin

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

cross-origin

Anfragen von jedem Origin (sowohl gleiche Site als auch unterschiedliche 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-Überprüfung lehnt der Browser no-cors-Anfragen von einem anderen Ursprung/Site ab, wenn der Header gesetzt ist.

Beziehung zur Cross-Origin Embedder Policy (COEP)

Der Cross-Origin-Embedder-Policy HTTP-Response-Header kann verwendet werden, um von einem Dokument aus zu verlangen, dass Unterressourcen entweder gleichen Ursprungs mit dem Dokument sind oder mit einem Cross-Origin-Resource-Policy HTTP-Response-Header kommen, um anzuzeigen, dass sie eingebettet werden dürfen. Aus diesem Grund existiert der Wert cross-origin.

Geschichte

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

Anfang 2018 wurden zwei Hardware-Sicherheitslücken, bekannt als Meltdown und Spectre, offengelegt. Diese Schwachstellen ermöglichten die Offenlegung sensibler Daten aufgrund eines Race-Conditions-Problems, das durch die spekulative Ausführungsfunktionalität entstand, die zur Leistungsverbesserung entwickelt wurde.

Als Reaktion darauf implementierte Chromium das Cross-Origin Read Blocking, das bestimmte Ressourcen (Content-Type HTML, JSON und XML) automatisch vor Cross-Origin-Lesungen schützt. Wenn die Anwendung keine no-sniff Direktive bereitstellt, wird Chromium versuchen, den Content-Type zu erraten und trotzdem den Schutz anzuwenden.

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

Spezifikationen

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

Browser-Kompatibilität

Siehe auch