Cross-Origin Resource Policy (CORP)

Cross-Origin Resource Policy ist eine Richtlinie, die durch den Cross-Origin-Resource-Policy HTTP-Header festgelegt wird. Diese ermöglicht es Websites und Anwendungen, sich gegen bestimmte Anfragen von anderen Ursprüngen (wie solche, die mit Elementen wie <script> und <img> verwendet 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 Standard-Same-Origin-Policy hinaus. Cross-Origin Resource Policy ergänzt Cross-Origin Read Blocking (CORB), ein Mechanismus, um einige Cross-Origin-Lesevorgänge standardmäßig zu verhindern.

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

Da diese Richtlinie über einen Response-Header ausgedrückt wird, wird die tatsächliche Anfrage nicht verhindert – stattdessen verhindert der Browser, dass das Ergebnis durchsickert, indem er den Antworttext entfernt.

Verwendung

Hinweis: Aufgrund eines Bugs in Chrome kann das Setzen des Cross-Origin-Resource-Policy Headers die PDF-Darstellung stören und verhindern, dass Besucher über die erste Seite einiger PDFs hinauslesen können. Seien Sie vorsichtig mit der Verwendung dieses Headers in einer Produktivumgebung.

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 derselben Site können die Ressource lesen.

Warnung: Dies ist weniger sicher als ein Origin. Der Algorithmus, um zu überprüfen, ob zwei Ursprünge auf derselben Seite sind, ist im HTML-Standard definiert und enthält eine Überprüfung der registrierbaren Domain.

same-origin

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

cross-origin

Anfragen von jedem Origin (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 ablehnen, die von einem anderen Origin/Site gesendet werden.

Beziehung zur cross-origin embedder policy (COEP)

Der Cross-Origin-Embedder-Policy HTTP-Response-Header kann, wenn er auf ein Dokument angewendet wird, verwendet werden, um zu verlangen, dass Subressourcen entweder gleiches Origin mit dem Dokument haben oder mit einem Cross-Origin-Resource-Policy HTTP-Response-Header kommen, um anzuzeigen, dass sie eingebettet werden dürfen. Aus diesem Grund existiert der cross-origin Wert.

Geschichte

Das Konzept wurde ursprünglich 2012 vorgeschlagen (als From-Origin), aber im Q2 von 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 Rennbedingung, die als Teil der spekulativen Ausführungsfunktion entstand, die darauf abzielt, die Leistung zu verbessern.

Als Reaktion veröffentlichte Chromium Cross-Origin Read Blocking, das automatisch bestimmte Ressourcen (vom Content-Type HTML, JSON und XML) gegen Cross-Origin-Lesevorgänge schützt. Wenn die Anwendung keine no-sniff-Direktive bereitstellt, wird Chromium versuchen, den Content-Type zu raten und den Schutz trotzdem anzuwenden.

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

Spezifikationen

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

Browser-Kompatibilität

BCD tables only load in the browser

Siehe auch