Cross-Origin Resource Policy (CORP)
Cross-Origin Resource Policy ist eine Richtlinie, die durch den Cross-Origin-Resource-Policy
HTTP-Header festgelegt wird und es Websites und Anwendungen ermöglicht, sich gegen bestimmte Anfragen von anderen Ursprüngen zu schützen (wie solche, die mit Elementen wie <script>
und <img>
erstellt werden), 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-Richtlinie hinaus. Cross-Origin Resource Policy ergänzt Cross-Origin Read Blocking (CORB), ein Mechanismus, der standardmäßig einige Cross-Origin-Lesezugriffe verhindert.
Hinweis:
Die Richtlinie ist nur bei no-cors
Anfragen wirksam, die standardmäßig für CORS-gesicherte Methoden/Header ausgegeben werden.
Da diese Richtlinie über einen Response-Header ausgedrückt wird, wird die eigentliche Anfrage nicht verhindert – vielmehr verhindert der Browser, dass das Ergebnis durchsickert, indem er den Antwortkörper entfernt.
Nutzung
Hinweis: Aufgrund eines Bugs in Chrome kann das Einstellen von Cross-Origin-Resource-Policy die PDF-Darstellung beeinträchtigen und verhindern, dass Besucher über die erste Seite einiger PDFs hinauslesen können. 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-Antwortheader, 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 zum Prüfen, ob zwei Ursprünge dieselbe Site sind ist im HTML-Standard definiert und bezieht das registrierbare Domain ein.
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).
Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin
Während einer Kontrolle der Cross-Origin Resource Policy, wenn der Header gesetzt ist, wird der Browser no-cors
Anfragen, die von einem anderen Ursprung/Site stammen, ablehnen.
Beziehung zur Cross-Origin Embedder Policy (COEP)
Der Cross-Origin-Embedder-Policy
HTTP-Antwortheader kann, wenn er in einem Dokument verwendet wird, verlangen, dass Unterressourcen entweder gleichherkunft mit dem Dokument sind oder mit einem Cross-Origin-Resource-Policy
HTTP-Antwortheader kommen, um anzuzeigen, dass sie mit der Einbettung einverstanden sind. Deshalb existiert der Wert cross-origin
.
Geschichte
Das Konzept wurde ursprünglich 2012 (als From-Origin
) vorgeschlagen, aber im Q2 2018 wiederbelebt und in Safari und Chromium implementiert.
Anfang 2018 wurden zwei Seitenkanal-Hardware-Schwachstellen namens Meltdown und Spectre bekanntgemacht. Diese Schwachstellen ermöglichten die Offenlegung sensibler Daten aufgrund einer Rennbedingung, die als Teil der spekulativen Ausführungsfunktionalität entstand, die entwickelt wurde, um die Leistung zu verbessern.
Als Reaktion darauf hat Chromium Cross-Origin Read Blocking eingeführt, das automatisch bestimmte Ressourcen (von Content-Type
HTML, JSON und XML) gegen Cross-Origin-Lesezugriffe schützt. Wenn die Anwendung keine no-sniff
Direktive ausgibt, wird Chromium versuchen, den Content-Type
zu erraten und den Schutz trotzdem anzuwenden.
Cross-Origin-Resource-Policy
ist ein Opt-in Antwortheader, der jede Ressource schützen kann; es ist nicht notwendig, dass Browser MIME-Typen untersuchen.
Spezifikationen
Specification |
---|
Fetch # cross-origin-resource-policy-header |
Browser-Kompatibilität
BCD tables only load in the browser
Siehe auch
Cross-Origin-Resource-Policy
HTTP Header