Cross-Origin Resource Sharing (CORS)

Dieser Cross-Origin-Sharing-Standard kann Cross-Origin-HTTP-Anfragen für folgende Zwecke ermöglichen:

• Aufrufe von fetch() oder XMLHttpRequest, wie oben beschrieben.
• Web Fonts (für die Nutzung von Schriftarten über Domains hinweg in @font-face innerhalb von CSS), damit Server TrueType-Schriftarten bereitstellen können, die nur cross-origin geladen und von Webseiten verwendet werden können, die dazu berechtigt sind.
• WebGL-Texturen.
• Bilder/Videoframes, die mit drawImage() auf eine Leinwand gezeichnet werden.
• CSS Shapes aus Bildern.

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

Der Cross-Origin Resource Sharing-Standard funktioniert, indem neue HTTP-Header hinzugefügt werden, die Servern erlauben, anzugeben, welche Quellen berechtigt sind, diese Informationen von einem Webbrowser zu lesen. Zusätzlich, für HTTP-Anfragemethoden, die Seiteneffekte auf Serverdaten verursachen können (insbesondere HTTP-Methoden, die nicht GET sind, oder POST mit bestimmten MIME-Typen), schreibt die Spezifikation vor, dass Browser die Anfrage "vorab untersuchen" (preflight), indem sie unterstützte Methoden vom Server mit der HTTP OPTIONS-Anfragemethode abrufen und dann, nach Freigabe durch den Server, die eigentliche Anfrage senden. Server können auch darüber informieren, ob "Anmeldeinformationen" (wie Cookies und HTTP-Authentifizierung) mit Anfragen gesendet werden sollen.

CORS-Fehler resultieren in Fehlern, aber aus Sicherheitsgründen sind die Einzelheiten des Fehlers für JavaScript nicht verfügbar. Alles, was der Code weiß, ist, dass ein Fehler aufgetreten ist. Der einzige Weg, um herauszufinden, was genau schiefgelaufen ist, besteht darin, die Konsole des Browsers auf Details zu überprüfen.

Nachfolgende Abschnitte behandeln Szenarien und bieten eine Aufschlüsselung der verwendeten HTTP-Header.

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

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

Die Motivation ist, dass das <form>-Element aus HTML 4.0 (das Cross-Site-fetch() und XMLHttpRequest vorausgeht) einfache Anfragen an jede Quelle senden kann, sodass jeder, der einen Server schreibt, sich bereits gegen Cross-Site-Request-Forgery (CSRF) schützen muss. Unter dieser Annahme muss der Server sich nicht anmelden (indem er auf eine Preflight-Anfrage antwortet), um jede Anfrage zu erhalten, die wie eine Formularübermittlung aussieht, da die Bedrohung durch CSRF nicht schlimmer ist als die durch eine Formularübermittlung. Der Server muss jedoch trotzdem using Access-Control-Allow-Origin opt-in wählen, um die Antwort mit dem Skript zu teilen.

Eine einfache Anfrage ist eine, die alle folgenden Bedingungen erfüllt:

• Eine der zulässigen 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-safe-listed Request-Header manuell gesetzt werden, und zwar:

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

• Die einzigen Typ-/Subtypkombinationen, 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 mithilfe eines XMLHttpRequest-Objekts gemacht wird, dürfen keine Ereignis-Listener auf dem durch die XMLHttpRequest.upload-Eigenschaft zurückgegebenen Objekt registriert werden, das in der Anfrage verwendet wird; das heißt, bei einer Instanz von XMLHttpRequest xhr darf kein Code xhr.upload.addEventListener() aufrufen, um einen Ereignis-Listener hinzuzufügen, der den Upload überwacht.

• Kein ReadableStream-Objekt wird in der Anfrage verwendet.

Angenommen, Webinhalte auf https://foo.example möchten JSON-Inhalte von der Domain https://bar.other abrufen. Solcher Code könnte im JavaScript von foo.example verwendet werden:

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

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

Diese Operation führt einen einfachen Austausch zwischen dem Client und dem Server durch und verwendet CORS-Header, um die Berechtigungen zu verwalten:

Schauen wir uns an, 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 bemerkenswerte Anforderungs-Header ist Origin, der zeigt, dass der Aufruf von https://foo.example kommt.

Nun sehen wir, 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 aus zugänglich ist.

Access-Control-Allow-Origin: *

Dieses Muster der Origin- und Access-Control-Allow-Origin-Header ist die einfachste Verwendung des Zugriffskontrollprotokolls. Wenn die Ressourceneigentümer auf https://bar.other den Zugriff auf die Ressource nur auf Anfragen von https://foo.example beschränken möchten (d.h. keine Domain außer https://foo.example kann auf die Ressource in einer Cross-Origin-Weise zugreifen), würden sie senden:

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

Anders als bei einfachen Anfragen sendet der Browser für "preflighted" Anfragen zunächst eine HTTP-Anfrage unter Verwendung der OPTIONS-Methode an die Ressource auf dem anderen Ursprung, um festzustellen, ob die tatsächliche Anfrage sicher gesendet werden kann. Solche Cross-Origin-Anfragen werden vorab kontrolliert (preflighted), da sie Auswirkungen auf Benutzerdaten haben können.

Das folgende ist ein Beispiel für eine Anfrage, die vorab kontrolliert 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. Zudem wird ein nicht standardmäßiger HTTP-Anforderungs-Header X-PINGOTHER gesetzt. Solche Header sind nicht Teil von HTTP/1.1, aber allgemein für Webanwendungen nützlich. Da die Anfrage einen Content-Type von text/xml verwendet und da ein benutzerdefinierter Header gesetzt ist, wird diese Anfrage vorab geprüft.

Schauen wir uns den gesamten Austausch zwischen Client und Server an. 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 stellt die Vorab-Anfrage mit der OPTIONS-Methode dar. Der Browser entscheidet, dass er dies aufgrund der Anfrageparameter senden muss, die der JavaScript-Code-Snippet oben verwendet hat, sodass der Server antworten kann, ob es zulässig ist, die Anfrage mit den tatsächlichen Anfrageparametern zu senden. OPTIONS ist eine HTTP/1.1-Methode, die verwendet wird, um weitere Informationen von Servern zu erhalten, und 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 weitere Anforderungs-Header 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, dass bei der tatsächlichen Anfrage eine POST-Anfragemethode verwendet wird. Der Access-Control-Request-Headers-Header benachrichtigt den Server, dass bei der tatsächlichen Anfrage die benutzerdefinierten Header X-PINGOTHER und Content-Type verwendet werden. Nun hat der Server die Möglichkeit zu bestimmen, ob er eine Anfrage unter diesen Bedingungen akzeptieren kann.

Der zweite Block oben ist die Antwort, die der Server zurückgibt, und zeigt an, dass die Anfragemethode (POST) und die Anforderungsheader (X-PINGOTHER) akzeptabel sind. Schauen 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, was den Zugriff nur auf die anfordernde Ursprung-Domain beschränkt. Er antwortet auch mit Access-Control-Allow-Methods, was angibt, dass POST und GET gültige Methoden sind, um die betreffende Ressource abzufragen (dieser Header ähnelt dem Allow-Antwort-Header, aber wird streng im Kontext der Zugriffskontrolle verwendet).

Der Server sendet auch 'Access-Control-Allow-Headers' mit einem Wert von X-PINGOTHER, Content-Type, was bestätigt, dass dies erlaubte Header sind, um mit der tatsächlichen Anfrage verwendet zu werden. Wie Access-Control-Allow-Methods ist Access-Control-Allow-Headers eine komma-separierte Liste von erlaubten Headern.

Schließlich gibt Access-Control-Max-Age den Wert in Sekunden an, für wie lange die Antwort auf die Preflight-Anfrage zwischengespeichert werden kann, ohne eine weitere Preflight-Anfrage senden zu müssen. Der Standardwert beträgt 5 Sekunden. In diesem Fall beträgt das maximale Alter 86400 Sekunden (= 24 Stunden). Beachten Sie, dass jeder Browser einen maximalen internen Wert hat, der Vorrang hat, wenn das 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]

Preflighted-Anfragen und Weiterleitungen

Nicht alle Browser unterstützen derzeit das Folgen von Weiterleitungen nach einer vorab geprüften Anfrage. Wenn eine Weiterleitung nach einer solchen Anfrage erfolgt, werden einige Browser derzeit eine Fehlermeldung wie die folgende melden:

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

Das CORS-Protokoll erforderte ursprünglich dieses Verhalten, wurde jedoch nachträglich geändert, um es nicht länger zu erfordern. Allerdings haben nicht alle Browser diese Änderung implementiert und zeigen daher noch das ursprünglich geforderte Verhalten.

Bis die Browser mit der Spezifikation aufholen, können Sie dieses Problem umgehen, indem Sie eine oder beide der folgenden Maßnahmen ergreifen:

• Ändern Sie das Verhalten auf der Serverseite, um die Preflight zu vermeiden und/oder um die Weiterleitung zu vermeiden
• Ändern Sie die Anfrage so, dass es sich um eine einfache Anfrage handelt, die keine Preflight auslöst

Wenn das nicht möglich ist, dann gibt es 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, welche URL die tatsächliche vorab geprüfte Anfrage erreichen würde.
2. Machen Sie eine weitere Anfrage (die eigentliche Anfrage), indem Sie die URL verwenden, die Sie aus Response.url oder XMLHttpRequest.responseURL im ersten Schritt erhalten haben.

Wenn die Anfrage jedoch aufgrund des Vorhandenseins des Authorization-Headers in der Anfrage eine Preflight auslöst, können Sie das Problem mit den oben genannten Schritten nicht umgehen. Und Sie können es überhaupt nicht umgehen, es sei denn, Sie haben Kontrolle über den Server, an den die Anfrage gestellt wird.

Die interessanteste Fähigkeit, die sowohl durch fetch() oder XMLHttpRequest als auch durch CORS freigelegt wird, ist die Möglichkeit, "anmeldungspflichtige" Anfragen durchzuführen, die über HTTP-Cookies und HTTP-Authentifizierungsdaten Bescheid wissen. Standardmäßig schicken Browser bei cross-origin fetch() oder XMLHttpRequest Anfragen keine Anmeldedaten.

Um bei einer fetch()-Anfrage Anmeldedaten anzufordern, setzen Sie die Option credentials auf "include".

Um bei einer XMLHttpRequest-Anfrage Anmeldedaten anzufordern, setzen Sie die Eigenschaft XMLHttpRequest.withCredentials 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. Inhalte auf foo.example könnten JavaScript-Code wie diesen 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 Option credentials im Konstruktor auf "include" setzt, und übergibt diese Anfrage dann an fetch(). Da dies eine einfache GET-Anfrage ist, wird sie nicht vorab kontrolliert, aber der Browser wird jede Antwort ablehnen, die nicht das Header Access-Control-Allow-Credentials: true hat, und wird nicht die Antwort für den aufrufenden Webinhalt verfügbar machen.

Hier ist ein Beispielaustausch 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 https://bar.other bestimmte Cookie enthält, würde die Antwort ignoriert und nicht für den Webinhalt verfügbar gemacht, wenn bar.other nicht mit einem Access-Control-Allow-Credentials mit dem Wert true antwortet, wie in diesem Beispiel gezeigt.

Preflight-Anfragen und Anmeldedaten

CORS-Preflight-Anfragen dürfen niemals Anmeldedaten enthalten. Die Antwort auf eine Preflight-Anfrage muss Access-Control-Allow-Credentials: true angeben, um anzuzeigen, dass die eigentliche Anfrage mit Anmeldedaten gemacht werden kann.

Anmeldepflichtige Anfragen und Wildcards

Beim Beantworten einer anmeldepflichtigen Anfrage:

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

Wenn eine Anfrage eine Anmeldedaten enthält (am häufigsten ein Cookie-Header) und die Antwort einen Access-Control-Allow-Origin: *-Header enthält (d.h. mit dem

Wildcard), blockiert der Browser den Zugriff auf die Antwort und meldet einen CORS-Fehler in der Entwicklerkonsole.

Wenn eine Anfrage jedoch Anmeldedaten enthält (wie den Cookie-Header) und die Antwort einen tatsächlichen Ursprung statt des Wildcards enthält (wie z.B. Access-Control-Allow-Origin: https://example.com), erlaubt der Browser den Zugriff auf die Antwort vom angegebenen Ursprung.

Außerdem würde ein Set-Cookie-Antwort-Header in einer Antwort kein Cookie setzen, wenn der Access-Control-Allow-Origin-Wert in dieser Antwort das *-Wildcard statt 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. In dem oben genannten Beispiel wird die Seite von foo.example geladen, aber der 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 er alle Drittanbieter-Cookies ablehnt.

Das Cookie in der Anfrage kann auch bei normalen Richtlinien für Drittanbieter-Cookies unterdrückt werden. Die erzwungene Cookie-Richtlinie kann daher die in diesem Kapitel beschriebene Fähigkeit außer Kraft setzen und effektiv verhindern, dass Sie anmeldepflichtige Anfragen überhaupt erstellen können.

Die Cookie-Richtlinie bezüglich des SameSite-Attributs würde gelten.

Dieser Abschnitt listet die HTTP-Antwort-Header 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.

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

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

Access-Control-Allow-Origin gibt entweder einen einzelnen Ursprung an, der den Browsern mitteilt, diesen Ursprung den Zugriff auf die Ressource zu erlauben, oder – für Anfragen ohne Anmeldedaten – der *-Wildcard erlaubt es Browsern, jedem Ursprung den Zugriff auf die Ressource zu erlauben.

Zum Beispiel, um Code von der Quelle https://mozilla.org den Zugriff auf die Ressource zu erlauben, können Sie angeben:

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

Wenn der Server einen einzelnen Ursprung angibt (der dynamisch basierend auf dem anfordernden Ursprung als Teil einer Erlaubensliste geändert werden kann) anstatt des *-Wildcards, sollte der Server auch Origin im Vary-Antwort-Header einschließen, um den Kunden mitzuteilen, dass Serverantworten abhängig vom Wert des Origin-Anforderungs-Headers unterschiedlich sein werden.

Der Access-Control-Expose-Headers-Header fügt die angegebenen Header zur Erlaubensliste hinzu, auf die JavaScript (wie Response.headers) in Browsern zugreifen darf.

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

Zum Beispiel, das folgende:

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

…würde es dem Browser erlauben, die Header X-My-Custom-Header und X-Another-Custom-Header anzuzeigen.

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 Parameter delta-seconds gibt die Anzahl der Sekunden an, für die die Ergebnisse zwischengespeichert werden können.

Der Access-Control-Allow-Credentials-Header zeigt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn das credentials-Flag wahr ist. Wenn er als Teil einer Antwort auf eine Preflight-Anfrage verwendet wird, gibt dies an, ob die tatsächliche Anfrage mit Anmeldedaten gemacht werden kann. Beachten Sie, dass einfache GET-Anfragen nicht vorab geprüft werden, und wenn eine Anfrage nach einer Ressource mit Anmeldedaten gemacht wird, wenn dieser Header nicht mit der Ressource zurückgegeben wird, wird die Antwort vom Browser ignoriert und nicht dem Webinhalt zurückgegeben.

Access-Control-Allow-Credentials: true

Anmeldepflichtige Anfragen werden oben diskutiert.

Der Access-Control-Allow-Methods-Header gibt die Methode oder Methoden an, die beim Zugriff auf die Ressource erlaubt sind. Dieser wird in der Antwort auf eine Preflight-Anfrage verwendet. Die Bedingungen, unter denen eine Anfrage vorab geprüft 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.

Der Access-Control-Allow-Headers-Header wird in der Antwort auf eine Preflight-Anfrage verwendet, um anzugeben, welche HTTP-Header verwendet werden können, wenn die tatsächliche Anfrage gemacht wird. Dieser Header ist die Serverseite-Antwort auf den Browser-Header Access-Control-Request-Headers.

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

Dieser Abschnitt listet die Header auf, die Kunden bei der Ausgabe von HTTP-Anfragen verwenden können, um die Cross-Origin-Sharing-Funktion zu nutzen. Beachten Sie, dass diese Header für Sie gesetzt werden, wenn Aufrufe an Server gemacht werden. Entwickler, die Cross-Origin-Anfragen stellen, müssen keine Cross-Origin-Sharing-Anforderungs-Header programmatisch setzen.

Der Origin-Header gibt den Ursprung der Cross-Origin-Zugriffsanfrage oder der Preflight-Anfrage an.

Origin: <origin>

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

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

Der Access-Control-Request-Method wird bei der Ausgabe 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.

Der Access-Control-Request-Headers-Header wird bei der Ausgabe einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die tatsächliche Anfrage gemacht wird (zum Beispiel, indem sie als headers-Option übergeben werden). Dieser Browser-Seiten-Header wird durch den komplementären Server-Seiten-Header Access-Control-Allow-Headers beantwortet.

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

Beispiele für diese Verwendung können oben gefunden werden.

• CORS-Fehler

• CORS aktivieren: Ich möchte CORS-Unterstützung zu meinem Server hinzufügen

• Fetch API

• XMLHttpRequest

• Will it CORS? - ein interaktiver CORS-Erklärer & Generator

• Anleitung zum Ausführen des Chrome-Browsers ohne CORS

• CORS mit allen (modernen) Browsern verwenden

• Stack Overflow Antwort mit "Anleitung"-Infos zum Umgang mit häufigen Problemen:

  • So vermeidet man die CORS-Preflight
  • So verwenden Sie einen CORS-Proxy, um das Problem "No Access-Control-Allow-Origin header" zu umgehen
  • So beheben Sie das Problem "Access-Control-Allow-Origin header must not be the wildcard"