Cross-Origin Resource Sharing (CORS)

Welche Anfragen verwenden CORS?

Dieser Standard für das Teilen zwischen Ursprüngen kann Cross-Origin HTTP-Anfragen ermöglichen für:

• Aufrufe von fetch() oder XMLHttpRequest, wie oben besprochen.
• Web-Schriftarten (für die Verwendung von Schriftarten-Domänen in @font-face innerhalb von CSS), wie in den Schriftanforderungen beschrieben, sodass Server TrueType-Schriftarten bereitstellen können, die nur cross-origin geladen und von Websites verwendet werden, die dazu berechtigt sind.
• WebGL-Texturen.
• Bilder/Video-Frames, die mit drawImage() auf einen Canvas gezeichnet werden.
• CSS-Formen aus Bildern.

Dies ist ein allgemeiner Artikel über Cross-Origin Resource Sharing und beinhaltet eine Diskussion über die notwendigen HTTP-Header.

Funktionaler Überblick

Der Cross-Origin Resource Sharing-Standard funktioniert durch das Hinzufügen neuer HTTP-Header, die Servern erlauben, zu beschreiben, welche Ursprünge berechtigt sind, diese Informationen von einem Webbrowser zu lesen. Zusätzlich, für HTTP-Anfragemethoden, die Seiteneffekte auf den Serverdaten verursachen können (insbesondere HTTP-Methoden, die nicht GET oder POST mit bestimmten MIME-Typen sind), schreibt die Spezifikation vor, dass Browser die Anfrage "vorbereiten" und die unterstützten Methoden vom Server mit der HTTP-Methode OPTIONS anfordern und dann, nach "Genehmigung" durch den Server, die tatsächliche Anfrage senden. Server können auch Clients darüber informieren, ob "Berechtigungsnachweise" (wie Cookies und HTTP-Authentifizierung) mit Anfragen gesendet werden sollten.

CORS-Fehler resultieren in Fehlern, aber aus Sicherheitsgründen sind Details zum Fehler nicht im JavaScript verfügbar. Der Code weiß nur, dass ein Fehler aufgetreten ist. Der einzige Weg, um festzustellen, was genau schiefgegangen ist, ist, die Konsole des Browsers für Details zu überprüfen.

In den folgenden Abschnitten werden Szenarien diskutiert und die verwendeten HTTP-Header aufgeschlüsselt.

Beispiele für Zugriffskontrollszenarien

Wir präsentieren drei Szenarien, die demonstrieren, wie Cross-Origin Resource Sharing funktioniert. Alle diese Beispiele verwenden fetch(), das in jedem unterstützenden Browser Cross-Origin-Anfragen stellen kann.

Einfache Anfragen

Einige Anfragen lösen keine CORS-Preflight aus. Diese werden einfache Anfragen genannt, basierend auf der veralteten CORS-Spezifikation, obwohl die Fetch-Spezifikation (die jetzt CORS definiert) diesen Begriff nicht verwendet.

Die Motivation besteht darin, dass das <form>-Element aus HTML 4.0 (das Cross-Sitefetch() und XMLHttpRequest vorausgeht) einfache Anfragen an jeden Ursprung senden kann, sodass jeder, der einen Server schreibt, sich bereits gegen CSRF verteidigen muss. Unter dieser Annahme muss der Server nicht zustimmen (indem er auf eine Preflight-Anfrage antwortet), eine Anfrage zu empfangen, die wie eine Formularübermittlung aussieht, da die Bedrohung durch CSRF nicht schlimmer ist als die Formularübermittlung. Der Server muss jedoch immer noch zustimmen, indem er Access-Control-Allow-Origin verwendet, um die Antwort mit dem Skript zu teilen.

Eine einfache Anfrage erfüllt alle folgenden Bedingungen:

• Eine der erlaubten Methoden:

  • GET
  • HEAD
  • POST

• Abgesehen von den automatisch durch den Benutzeragenten gesetzten Headern (zum Beispiel Connection, User-Agent, oder den verbotenen Anforderungsheadern), dürfen nur die CORS-sicherheitsgelistet Anforderungs-Header manuell gesetzt werden:

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (beachten Sie bitte die zusätzlichen Anforderungen unten)
  • Range (nur mit einem einzelnen Bereichsheader-Wert; z.B., bytes=256- oder bytes=127-255)

• Die einzigen Typ-/Subtyp-Kombinationen, die für den Medientyp im Content-Type-Header erlaubt sind, sind:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

• Wenn die Anfrage mit einem XMLHttpRequest Objekt gemacht wird, sind keine Event-Listener auf dem durch die XMLHttpRequest.upload Rückgabeobjekt registriert; das bedeutet, für eine XMLHttpRequest Instanz xhr hat kein Code xhr.upload.addEventListener() aufgerufen, um einen Event-Listener hinzuzufügen, der den Upload überwacht.

• Kein ReadableStream Objekt wird in der Anfrage verwendet.

Auf ein Beispiel: Angenommen, web content unter https://foo.example möchte JSON-Inhalte von der Domain https://bar.other abrufen. Code dieser Art könnte in JavaScript bereitgestellt werden auf foo.example:

const fetchPromise = fetch("https://bar.other");

fetchPromise
  .then((response) => response.json())
  .then((data) => {
    console.log(data);
  });

Dieser Vorgang führt zu einem einfachen Austausch zwischen dem Client und dem Server, bei dem CORS-Header zur Handhabung der Berechtigungen verwendet werden:

Werfen wir einen Blick darauf, was der Browser in diesem Fall an den Server senden wird:

GET /resources/public-data/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example

Der erwähnenswerte Anfrageheader ist Origin, der zeigt, dass der Aufruf von https://foo.example stammt.

Sehen wir uns nun an, wie der Server antwortet:

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 00:23:53 GMT
Server: Apache/2
Access-Control-Allow-Origin: *
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml

[…XML Data…]

In der Antwort gibt der Server einen Access-Control-Allow-Origin Header mit Access-Control-Allow-Origin: * zurück, was bedeutet, dass die Ressource von jedem Ursprung abgerufen werden kann.

Access-Control-Allow-Origin: *

Dieses Muster der Origin und Access-Control-Allow-Origin Header ist der einfachste Gebrauch des Zugriffskontrollprotokolls. Wenn die Ressourceneigentümer bei https://bar.other den Zugriff auf die Ressource einschränken möchten, sodass nur Anfragen von https://foo.example (d.h. keine andere Domain als https://foo.example kann die Ressource im Cross-Origin-Modus abrufen), würden sie senden:

Access-Control-Allow-Origin: https://foo.example

Preflighted-Anfragen

Anders als bei einfachen Anfragen, sendet der Browser bei "preflighted" Anfragen zuerst eine HTTP-Anfrage mit der OPTIONS Methode an die Ressource im anderen Ursprung, um zu bestimmen, ob die tatsächliche Anfrage sicher gesendet werden kann. Solche Cross-Origin-Anfragen werden vorverarbeitet, da sie Auswirkungen auf die Benutzerdaten haben können.

Das Folgende ist ein Beispiel für eine Anfrage, die vorverarbeitet wird:

const fetchPromise = fetch("https://bar.other/doc", {
  method: "POST",
  mode: "cors",
  headers: {
    "Content-Type": "text/xml",
    "X-PINGOTHER": "pingpong",
  },
  body: "<person><name>Arun</name></person>",
});

fetchPromise.then((response) => {
  console.log(response.status);
});

Das obige Beispiel erstellt einen XML-Body, der mit der POST-Anfrage gesendet wird. Außerdem ist ein nicht-standardisierter HTTP X-PINGOTHER Anforderungs-Header gesetzt. Solche Header sind nicht Teil von HTTP/1.1, sind aber generell für Webanwendungen nützlich. Da die Anfrage einen Content-Type von text/xml verwendet und ein benutzerdefinierter Header gesetzt ist, wird diese Anfrage vorverarbeitet.

Werfen wir einen Blick auf den vollständigen Austausch zwischen Client und Server. Der erste Austausch ist die Preflight-Anfrage/-Antwort:

OPTIONS /doc HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Origin: https://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type,x-pingother

HTTP/1.1 204 No Content
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive

Der erste Block oben repräsentiert die vorverarbeitete Anfrage mit der OPTIONS Methode. Der Browser stellt fest, dass er dies basierend auf den Anforderungsparametern senden muss, die der obige JavaScript-Codeausschnitt verwendet, sodass der Server antworten kann, ob es akzeptabel ist, die Anfrage mit den tatsächlichen Anforderungsparametern zu senden. OPTIONS ist eine HTTP/1.1 Methode, die dazu verwendet wird, weitere Informationen von Servern zu erhalten, und es ist eine sichere Methode, was bedeutet, dass sie nicht verwendet werden kann, um die Ressource zu ändern. Beachten Sie, dass zusammen mit der OPTIONS-Anfrage zwei andere Anforderungsheader gesendet werden:

Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type,x-pingother

Der Access-Control-Request-Method Header benachrichtigt den Server als Teil einer preflight Anfrage darüber, dass, wenn die tatsächliche Anfrage gesendet wird, sie mit einer POST Anforderungsmethode erfolgen wird. Der Access-Control-Request-Headers Header benachrichtigt den Server darüber, dass, wenn die tatsächliche Anfrage gesendet wird, sie mit den benutzerdefinierten Headern X-PINGOTHER und Content-Type erfolgen wird. Jetzt hat der Server die Möglichkeit zu bestimmen, ob unter diesen Bedingungen eine Anfrage akzeptiert werden kann.

Der zweite Block oben ist die Antwort, die der Server zurückgibt, welche angibt, dass die Anforderungsmethode (POST) und die Anforderungs-Header (X-PINGOTHER) akzeptabel sind. Sehen wir uns die folgenden Zeilen genauer an:

Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400

Der Server antwortet mit Access-Control-Allow-Origin: https://foo.example, wodurch der Zugriff nur auf die Domain des anfordernden Ursprungs beschränkt wird. Er antwortet auch mit Access-Control-Allow-Methods, was besagt, dass POST und GET gültige Methoden sind, um die betreffende Ressource abzufragen (dieser Header ist ähnlich dem Allow Antwort-Header, wird aber streng im Kontext der Zugangskontrolle verwendet).

Der Server sendet auch Access-Control-Allow-Headers mit einem Wert von X-PINGOTHER, Content-Type, um zu bestätigen, dass dies zulässige Header sind, die mit der tatsächlichen Anfrage verwendet werden können. Wie Access-Control-Allow-Methods ist Access-Control-Allow-Headers eine kommagetrennte Liste von zulässigen Headern.

Zuletzt gibt Access-Control-Max-Age den Wert in Sekunden an, wie lange die Antwort auf die Preflight-Anfrage zwischengespeichert werden kann, ohne eine weitere Preflight-Anfrage zu senden. Der Standardwert beträgt 5 Sekunden. Im aktuellen Fall beträgt das maximale Alter 86400 Sekunden (= 24 Stunden). Beachten Sie, dass jeder Browser einen maximalen internen Wert hat, der Vorrang hat, wenn die Access-Control-Max-Age diesen überschreitet.

Sobald die Preflight-Anfrage abgeschlossen ist, wird die tatsächliche Anfrage gesendet:

POST /doc HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: https://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: https://foo.example
Pragma: no-cache
Cache-Control: no-cache

<person><name>Arun</name></person>

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain

[Some XML content]

Preflight-Anfragen und Weiterleitungen

Nicht alle Browser unterstützen zurzeit das Folgen von Weiterleitungen nach einer vorverarbeiteten Anfrage. Wenn nach solch einer Anfrage eine Weiterleitung erfolgt, zeigen einige Browser derzeit eine Fehlermeldung wie die folgende an:

Die Anfrage wurde an https://example.com/foo weitergeleitet, was für Cross-Origin-Anfragen, die Preflight benötigen, nicht erlaubt ist. Anfrage erfordert Preflight, das ist nicht erlaubt, um Cross-Origin-Weiterleitungen zu folgen.

Das CORS-Protokoll hat ursprünglich dieses Verhalten erfordert, wurde aber anschließend geändert, um es nicht mehr zu erfordern. Allerdings haben nicht alle Browser die Änderung implementiert und zeigen deswegen noch das ursprünglich geforderte Verhalten.

Bis die Browser mit der Spezifikation mithalten, können Sie möglicherweise diese Einschränkung umgehen, indem Sie Folgendes tun:

• Ändern Sie das serverseitige Verhalten, um die Preflight zu vermeiden und/oder die Umleitung zu vermeiden
• Ändern Sie die Anfrage so, dass es eine einfache Anfrage ist, die keine Preflight verursacht

Wenn das nicht möglich ist, ist eine andere Möglichkeit:

1. Machen Sie eine einfache Anfrage (unter Verwendung von Response.url für die Fetch API oder XMLHttpRequest.responseURL), um zu bestimmen, zu welcher URL die eigentliche vorverarbeitete Anfrage führen würde.
2. Machen Sie eine weitere Anfrage (die tatsächliche Anfrage) unter Verwendung der URL, die Sie im ersten Schritt von Response.url oder XMLHttpRequest.responseURL erhalten haben.

Wenn die Anfrage jedoch eine ist, die eine Preflight aufgrund des Vorhandenseins des Authorization Headers in der Anfrage auslöst, werden Sie diese Einschränkung nicht mit den oben beschriebenen Schritten umgehen können. Und Sie werden sie überhaupt nicht umgehen können, es sei denn, Sie haben die Kontrolle über den Server, an den die Anfrage geschickt wird.

Anfragen mit Berechtigungsnachweisen

Die interessanteste Funktion, die sowohl von fetch() als auch von XMLHttpRequest und CORS offenbart wird, ist die Möglichkeit, „berechtigte” Anfragen zu stellen, die sich HTTP-Cookies und HTTP-Authentifizierungsinformationen bewusst sind. Standardmäßig senden Browser in Cross-Origin-fetch()- oder XMLHttpRequest-Aufrufen keine Berechtigungsnachweise.

Um eine fetch()-Anfrage so zu gestalten, dass sie Berechtigungsnachweise enthält, setzen Sie die credentials Option auf "include".

Um eine XMLHttpRequest-Anfrage so zu gestalten, dass sie Berechtigungsnachweise enthält, setzen Sie die XMLHttpRequest.withCredentials Eigenschaft auf true.

In diesem Beispiel macht der Inhalt, der ursprünglich von https://foo.example geladen wurde, eine GET-Anfrage an eine Ressource auf https://bar.other, die Cookies setzt. Inhalt auf foo.example könnte JavaScript wie dieses enthalten:

const url = "https://bar.other/resources/credentialed-content/";

const request = new Request(url, { credentials: "include" });

const fetchPromise = fetch(request);
fetchPromise.then((response) => console.log(response));

Dieser Code erstellt ein Request Objekt, das die credentials Option im Konstruktor auf "include" setzt und gibt dann diese Anfrage in fetch() ein. Da dies eine einfache GET-Anfrage ist, wird sie nicht vorverarbeitet, aber der Browser wird jede Antwort ablehnen, die nicht den Access-Control-Allow-Credentials Header auf true gesetzt hat, und die Antwort nicht dem aufrufenden Webinhalt verfügbar machen.

Hier ist ein Beispiel für einen Austausch zwischen Client und Server:

GET /resources/credentialed-content/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Connection: keep-alive
Referer: https://foo.example/examples/credential.html
Origin: https://foo.example
Cookie: pageAccess=2

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:34:52 GMT
Server: Apache/2
Access-Control-Allow-Origin: https://foo.example
Access-Control-Allow-Credentials: true
Cache-Control: no-cache
Pragma: no-cache
Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 106
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

[text/plain content]

Obwohl der Cookie Header der Anfrage das für die Inhalte der https://bar.other bestimmte Cookie enthält, würde die Antwort ignoriert und nicht für den Webinhalt verfügbar gemacht werden, wenn bar.other nicht mit einem Access-Control-Allow-Credentials mit dem Wert true antwortet, wie in diesem Beispiel demonstriert.

Preflight-Anfragen und Berechtigungsnachweise

CORS-Preflight-Anfragen dürfen niemals Berechtigungsnachweise enthalten. Die Antwort auf eine Preflight-Anfrage muss Access-Control-Allow-Credentials: true angeben, um zu zeigen, dass die tatsächliche Anfrage mit Berechtigungsnachweisen gemacht werden kann.

Berechtigte Anfragen und Platzhalter

Wenn auf eine berechtigte Anfrage geantwortet wird:

• Der Server darf nicht das * Platzhalterzeichen für den Access-Control-Allow-Origin Antwortheader-Wert angeben, sondern muss stattdessen einen spezifischen Ursprung angeben; zum Beispiel: Access-Control-Allow-Origin: https://example.com
• Der Server darf nicht das * Platzhalterzeichen für den Access-Control-Allow-Headers Antwortheader-Wert angeben, sondern muss stattdessen eine explizite Liste von Header-Namen angeben; zum Beispiel, Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
• Der Server darf nicht das * Platzhalterzeichen für den Access-Control-Allow-Methods Antwortheader-Wert angeben, sondern muss stattdessen eine explizite Liste von Methodennamen angeben; zum Beispiel, Access-Control-Allow-Methods: POST, GET
• Der Server darf nicht das * Platzhalterzeichen für den Access-Control-Expose-Headers Antwortheader-Wert angeben, sondern muss stattdessen eine explizite Liste von Header-Namen angeben; zum Beispiel, Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision

Wenn eine Anfrage ein Berechtigungsnachweis enthält (meistens ein Cookie Header) und die Antwort einen Access-Control-Allow-Origin: * Header enthält (also mit dem Platzhalter), wird der Browser den Zugriff auf die Antwort blockieren und einen CORS-Fehler in der Devtools-Konsole protokollieren.

Aber wenn eine Anfrage ein Berechtigungsnachweis enthält (wie den Cookie Header) und die Antwort einen tatsächlichen Ursprung anstelle des Platzhalters enthält (zum Beispiel Access-Control-Allow-Origin: https://example.com), dann wird der Browser den Zugriff auf die Antwort vom angegebenen Ursprung zulassen.

Beachten Sie auch, dass jeder Set-Cookie Antwortheader in einer Antwort kein Cookie setzen würde, wenn der Access-Control-Allow-Origin Wert in dieser Antwort das * Platzhalterzeichen anstelle eines tatsächlichen Ursprungs ist.

Drittanbieter-Cookies

Beachten Sie, dass Cookies, die in CORS-Antworten gesetzt werden, den normalen Richtlinien für Drittanbieter-Cookies unterliegen. Im obigen Beispiel wird die Seite von foo.example geladen, aber der Set-Cookie Header in der Antwort wird von bar.other gesendet und würde daher nicht gespeichert, wenn der Browser des Benutzers so konfiguriert ist, dass alle Drittanbieter-Cookies abgelehnt werden.

Cookies, die in CORS-Anfragen und -Antworten gesetzt werden, unterliegen den normalen Richtlinien für Drittanbieter-Cookies.

Drittanbieter-Cookie-Richtlinien können verhindern, dass Drittanbieter-Cookies in Anfragen gesendet werden, und effektiv eine Site daran hindern, berechtigte Anfragen zu stellen, selbst wenn dies vom Drittanbieter-Server erlaubt ist (Verwendung von Access-Control-Allow-Credentials). Die Standardrichtlinie unterscheidet sich zwischen Browsern, kann jedoch mit dem SameSite Attribut festgelegt werden.

Selbst wenn berechtigte Anfragen erlaubt sind, kann es vorkommen, dass ein Browser dafür eingerichtet ist, alle Drittanbieter-Cookies in Antworten abzulehnen.

Die HTTP Antwort-Header

Dieser Abschnitt listet die HTTP-Antwortheader auf, die Server für Zugriffskontrollanfragen gemäß der Cross-Origin Resource Sharing-Spezifikation zurückgeben. Der vorherige Abschnitt gibt einen Überblick über diese in Aktion.

Access-Control-Allow-Origin

Eine zurückgegebene Ressource kann einen Access-Control-Allow-Origin Header mit folgendem Syntax haben:

Access-Control-Allow-Origin: <origin> | *

Access-Control-Allow-Origin gibt entweder einen einzelnen Ursprung an, der Browsern erlaubt, auf diese Ressource zuzugreifen, oder — für Anfragen ohne Berechtigungsnachweise — das * Platzhalterzeichen erlaubt Browsern, von jedem Ursprung auf die Ressource zuzugreifen.

Um beispielsweise zu erlauben, dass Code aus dem Ursprung https://mozilla.org auf die Ressource zugreift, können Sie angeben:

Access-Control-Allow-Origin: https://mozilla.org
Vary: Origin

Wenn der Server einen einzelnen Ursprung angibt (der sich je nach dem anfordernden Ursprung als Teil einer Whitelist dynamisch ändern kann) anstelle des * Platzhalters, sollte der Server auch Origin im Vary Antwortheader einschließen, um den Clients mitzuteilen, dass die Serverantworten basierend auf dem Wert des Origin Anfrageheaders variieren werden.

Access-Control-Expose-Headers

Der Access-Control-Expose-Headers Header fügt die angegebenen Header zur Whitelist hinzu, die von JavaScript (wie Response.headers) in Browsern zugegriffen werden darf.

Access-Control-Expose-Headers: <header-name>[, <header-name>]*

Zum Beispiel würde das Folgende die Header X-My-Custom-Header und X-Another-Custom-Header für den Browser verfügbar machen:

Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header

Access-Control-Max-Age

Der Access-Control-Max-Age Header gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden können. Ein Beispiel für eine Preflight-Anfrage finden Sie in den obigen Beispielen.

Access-Control-Max-Age: <delta-seconds>

Der delta-seconds Parameter gibt die Anzahl der Sekunden an, wie lange die Ergebnisse zwischengespeichert werden können.

Access-Control-Allow-Credentials

Der Access-Control-Allow-Credentials Header gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das credentials Flag wahr ist. Wenn es als Teil einer Antwort auf eine Preflight-Anfrage verwendet wird, gibt es an, ob die tatsächliche Anfrage mit Berechtigungsnachweisen gestellt werden kann. Beachten Sie, dass einfache GET-Anfragen nicht vorbearbeitet werden und so, wenn eine Anfrage für eine Ressource mit Anmeldeinformationen gestellt wird, wenn dieser Header nicht mit der Ressource zurückgegeben wird, wird die Antwort vom Browser ignoriert und nicht an den Webinhalt zurückgegeben.

Access-Control-Allow-Credentials: true

Berechtigte Anfragen werden oben diskutiert.

Access-Control-Allow-Methods

Der Access-Control-Allow-Methods Header spezifiziert die Methode oder Methoden, die beim Zugriff auf die Ressource erlaubt sind. Dies wird als Antwort auf eine Preflight-Anfrage verwendet. Die Bedingungen, unter denen eine Anfrage vorverarbeitet wird, werden oben diskutiert.

Access-Control-Allow-Methods: <method>[, <method>]*

Ein Beispiel für eine Preflight-Anfrage wird oben gegeben, einschließlich eines Beispiels, das diesen Header an den Browser sendet.

Access-Control-Allow-Headers

Der Access-Control-Allow-Headers Header wird als Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header verwendet werden können, wenn die tatsächliche Anfrage gestellt wird. Dieser Header ist die serverseitige Antwort auf den Access-Control-Request-Headers Header des Browsers.

Access-Control-Allow-Headers: <header-name>[, <header-name>]*

Die HTTP-Anfrageheader

Dieser Abschnitt listet Header auf, die Clients beim Ausgeben von HTTP-Anfragen verwenden können, um die Funktion der gemeinsamen Nutzung zwischen Ursprüngen zu nutzen. Beachten Sie, dass diese Header für Sie gesetzt werden, wenn Sie Aufrufe zu Servern machen. Entwickler, die Cross-Origin-Anfragen machen, müssen keine Cross-Origin-Sharing-Anfrageheader programmatisch festlegen.

Origin

Der Origin Header gibt den Ursprung der Cross-Origin-Zugriffsanforderung oder Preflight-Anforderung an.

Origin: <origin>

Der Ursprung ist eine URL, die den Server angibt, von dem die Anfrage initiiert wurde. Sie enthält keine Pfadinformationen, nur den Servernamen.

Beachten Sie, dass in jeder Zugriffskontrollanfrage der Origin Header immer gesendet wird.

Access-Control-Request-Method

Der Access-Control-Request-Method wird beim Ausgeben einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode verwendet wird, wenn die tatsächliche Anfrage gemacht wird.

Access-Control-Request-Method: <method>

Beispiele für diese Verwendung finden Sie oben.

Access-Control-Request-Headers

Der Access-Control-Request-Headers Header wird beim Ausgeben einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die tatsächliche Anfrage gemacht wird (zum Beispiel, indem man sie als headers Option übergibt). Dieser Browser-seitige Header wird von dem komplementären server-seitigen Header von Access-Control-Allow-Headers beantwortet.

Access-Control-Request-Headers: <field-name>[,<field-name>]*

Beispiele für diese Verwendung finden Sie oben.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• CORS-Fehler
• Enable CORS: Ich möchte CORS-Unterstützung zu meinem Server hinzufügen
• Fetch API
• XMLHttpRequest
• Wird es CORS? - ein interaktiver CORS-Erklärer & Generator
• Wie man den Chrome-Browser ohne CORS ausführt
• CORS mit allen (modernen) Browsern verwenden
• Stack Overflow-Antwort mit "Anleitung" Informationen zum Umgang mit häufigen Problemen:
  • Wie man das CORS-Preflight vermeidet
  • Wie man einen CORS-Proxy verwendet, um das "Kein Access-Control-Allow-Origin-Header" zu umgehen
  • Wie man das "Access-Control-Allow-Origin-Header darf nicht das Platzhalter sein" behebt