Cross-Origin Resource Sharing (CORS)

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

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

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

Der Cross-Origin Resource Sharing-Standard funktioniert durch das Hinzufügen neuer HTTP-Header, die Servern ermöglichen, zu beschreiben, welche Ursprünge berechtigt sind, Informationen von einem Webbrowser zu lesen. Zusätzlich dazu verlangt die Spezifikation für HTTP-Anfragemethoden, die Seiteneffekte auf Serverdaten verursachen können (insbesondere HTTP-Methoden andere als GET, oder POST mit bestimmten MIME-Typen), dass Browser die Anfrage in einem "Preflight" überprüfen, indem sie die unterstützten Methoden mit der HTTP OPTIONS-Anfragemethode beim Server anfordern und dann die eigentliche Anfrage senden, nachdem der Server zugestimmt hat. Server können auch den Clients mitteilen, ob "Anmeldeinformationen" (wie Cookies und HTTP-Authentifizierung) mit Anfragen gesendet werden sollen.

CORS-Fehler führen zu Fehlern, aber aus Sicherheitsgründen sind Einzelheiten zu dem Fehler für JavaScript nicht verfügbar. Der gesamte Code weiß nur, dass ein Fehler aufgetreten ist. Der einzige Weg, um festzustellen, was genau schiefgegangen ist, besteht darin, sich die Konsole des Browsers anzusehen.

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

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

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

Der Grundgedanke ist, dass das <form>-Element aus HTML 4.0 (das cross-site fetch() und XMLHttpRequest vorausgeht) einfache Anfragen an jeden Ursprung senden kann, sodass jeder, der einen Server schreibt, bereits gegen Cross-Site request forgery (CSRF) geschützt sein muss. Unter dieser Annahme muss der Server nicht zustimmen (durch das Antworten auf eine Preflight-Anfrage), jede Anfrage zu erhalten, die wie ein Formularversand aussieht, da die Bedrohung durch CSRF nicht schlimmer als die eines Formularversands ist. Der Server muss jedoch weiterhin mit Access-Control-Allow-Origin zustimmen, um die Antwort mit dem Skript zu teilen.

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

• Eine der erlaubten Methoden:

  • GET
  • HEAD
  • POST

• Abgesehen von den vom Benutzeragenten automatisch gesetzten Headern (z. B. Connection, User-Agent oder den verbotenen Anforderungs-Headern) sind die einzigen Header, die manuell gesetzt werden dürfen, die CORS-safelisted request-headers, die sind:

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

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

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

• Wenn die Anfrage mit einem XMLHttpRequest-Objekt gemacht wird, sind keine Ereignislistener auf dem Objekt registriert, das von der XMLHttpRequest.upload-Eigenschaft verwendet wird; das heißt, kein Code hat xhr.upload.addEventListener() aufgerufen, um einen Eventlistener hinzuzufügen, der den Upload überwacht, gegeben ein XMLHttpRequest-Instanz xhr.

• Kein ReadableStream-Objekt wird in der Anfrage verwendet.

Angenommen, Webinhalt unter https://foo.example möchte JSON-Inhalt von der Domain https://bar.other abrufen. Ähnlicher Code könnte in JavaScript auf foo.example eingesetzt sein:

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, wobei CORS-Header verwendet werden, um die Berechtigungen zu regeln:

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.

Sehen wir nun, 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 auf die Ressource von jedem Ursprung zugegriffen werden kann.

Access-Control-Allow-Origin: *

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

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

Im Gegensatz zu einfachen Anfragen sendet der Browser bei "preflighted" Anfragen zuerst eine HTTP-Anfrage mit der OPTIONS Methode an die Ressource auf dem anderen Ursprung, um festzustellen, ob die tatsächliche Anfrage sicher zu senden ist. Solche Cross-Origin-Anfragen sind vorab ausgelöst, da sie Auswirkungen auf Benutzerdaten haben können.

Im Folgenden ist ein Beispiel für eine Anfrage, die vorab überprüft 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 werden soll. Außerdem wird ein nicht standardmäßiger HTTP X-PINGOTHER Anforderungs-Header gesetzt. Solche Header sind kein Teil von HTTP/1.1, aber für Webanwendungen im Allgemeinen nützlich. Da die Anfrage einen Content-Type von text/xml verwendet und da ein benutzerdefinierter Header gesetzt ist, wird diese Anfrage vorab überprüft.

Schauen wir uns den vollständigen Austausch zwischen dem Client und dem 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 repräsentiert die Preflight-Anfrage mit der OPTIONS Methode. Der Browser entscheidet anhand der Anforderungsparameter, die der im vorherigen Abschnitt verwendete JavaScript-Code-Snippet verwendet, dass er diese senden muss, 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 verwendet wird, um weitere Informationen von Servern zu erhalten, und ist eine sichere Methode, was bedeutet, dass sie nicht genutzt werden kann, um die Ressource zu ändern. Beachten Sie, dass zusammen mit der OPTIONS-Anfrage zwei andere Anforderungs-Header gesendet werden:

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

Der Access-Control-Request-Method Header informiert den Server als Teil einer Preflight-Anfrage darüber, dass beim Senden der tatsächlichen Anfrage eine POST Anfragemethode verwendet wird. Der Access-Control-Request-Headers Header informiert den Server darüber, dass beim Senden der tatsächlichen Anfrage X-PINGOTHER und Content-Type benutzerdefinierte Header verwendet werden. Nun hat der Server die Möglichkeit festzustellen, ob er eine Anfrage unter diesen Bedingungen akzeptieren kann.

Der zweite Block oben ist die Antwort, die der Server zurücksendet und angibt, dass die Anfragemethode (POST) und die Anforderungs-Header (X-PINGOTHER) akzeptabel sind. Betrachten wir näher die folgenden Zeilen:

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 auf die anfordernde Ursprung Domain beschränkt wird. Er antwortet auch mit Access-Control-Allow-Methods, das besagt, dass POST und GET gültige Methoden sind, um die Ressource in Frage zu stellen (dieser Header ist ähnlich dem Allow Antwort-Header, wird aber streng im Kontext der Zugriffssteuerung verwendet).

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

Schließlich gibt Access-Control-Max-Age den Wert in Sekunden an, wie lange die Antwort auf die Preflight-Anfrage ohne Senden einer weiteren Preflight-Anfrage zwischengespeichert werden kann. Der Standardwert beträgt 5 Sekunden. Im gegenwärtigen 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]

Preflighted Anfragen und Weiterleitungen

Nicht alle Browser unterstützen derzeit das Folgen von Weiterleitungen nach einer vorübergehenden Anfrage. Wenn nach einer solchen Anfrage eine Weiterleitung auftritt, melden einige Browser derzeit eine Fehlermeldung wie folgende:

Die Anfrage wurde nach https://example.com/foo umgeleitet, was für Cross-Origin-Anfragen nicht zulässig ist, die ein Preflight erfordern. Die Anfrage erfordert Preflight, das nicht folgen darf Cross-Origin-Weiterleitungen.

Das CORS-Protokoll erforderte ursprünglich dieses Verhalten, wurde jedoch später geändert, um es nicht mehr zu verlangen. Nicht alle Browser haben die Änderung implementiert und halten daher weiterhin das ursprünglich geforderte Verhalten aufrecht.

Bis die Browser mit der Spezifikation aufgeholt haben, können Sie möglicherweise diese Einschränkung umgehen, indem Sie eine oder beide der folgenden Maßnahmen ergreifen:

• Ändern Sie das serverseitige Verhalten, um das Preflight zu vermeiden und/oder die Weiterleitung zu vermeiden
• Ändern Sie die Anfrage so, dass sie eine einfache Anfrage ist, die kein Preflight verursacht

Wenn das nicht möglich ist, dann 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 herauszufinden, an welche URL die tatsächliche vorabgeprüfte Anfrage gelangen würde.
2. Machen Sie eine weitere Anfrage (die tatsächliche Anfrage) unter Verwendung der URL, die Sie aus Response.url oder XMLHttpRequest.responseURL im ersten Schritt erhalten haben.

Wenn die Anfrage jedoch die Anforderung eines Präflights wegen der Existenz des Authorization Headers in der Anfrage auslöst, können Sie die Einschränkung nicht mit den oben beschriebenen Schritten 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() als auch XMLHttpRequest und CORS freigelegt wird, ist die Möglichkeit, "anmeldedatumsgestützte" Anfragen zu stellen, die sich der HTTP-Cookies und HTTP-Authentifizierungsinformationen bewusst sind. Standardmäßig senden Browser keine Anmeldeinformationen bei Cross-Origin fetch() oder XMLHttpRequest Aufrufen.

Um eine fetch()-Anfrage zu stellen, die Anmeldeinformationen enthält, setzen Sie die credentials Option auf "include".

Um eine XMLHttpRequest-Anfrage zu stellen, die Anmeldeinformationen enthält, setzen Sie die XMLHttpRequest.withCredentials Eigenschaft auf true.

In diesem Beispiel fordert der ursprünglich von https://foo.example geladene Inhalt eine GET-Anfrage zu einer Ressource auf https://bar.other an, die Cookies setzt. Der 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, bei dem die credentials Option im Konstruktor auf "include" gesetzt wird, und übergibt diese Anfrage dann an fetch(). Da dies eine einfache GET-Anfrage ist, wird sie nicht vorab überprüft, aber der Browser wird jede Antwort ablehnen, die nicht den Access-Control-Allow-Credentials Header mit dem Wert true enthält, und macht die Antwort nicht für den aufrufenden Web-Inhalt verfügbar.

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 den für den Inhalt auf https://bar.other bestimmten Cookie enthält, würde die Antwort ignoriert und dem Web-Inhalt nicht zur Verfügung gestellt werden, wenn bar.other nicht mit einem Access-Control-Allow-Credentials mit dem Wert true antworten würde, wie in diesem Beispiel demonstriert.

Preflight-Anfragen und Anmeldeinformationen

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

Anfragen mit Anmeldeinformationen und Wildcards

Bei der Beantwortung einer Anforderung mit Anmeldeinformationen:

• Der Server darf nicht das *-Wildcard für den Access-Control-Allow-Origin-Antwort-Header-Wert angeben, muss stattdessen aber einen expliziten Ursprung angeben; zum Beispiel: Access-Control-Allow-Origin: https://example.com
• Der Server darf nicht das *-Wildcard für den Access-Control-Allow-Headers-Antwort-Header-Wert angeben, muss stattdessen aber 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 Access-Control-Allow-Methods-Antwort-Header-Wert angeben, muss stattdessen aber eine explizite Liste von Methodennamen angeben; zum Beispiel, Access-Control-Allow-Methods: POST, GET
• Der Server darf nicht das *-Wildcard für den Access-Control-Expose-Headers-Antwort-Header-Wert angeben, muss stattdessen aber eine explizite Liste von Headernamen angeben; zum Beispiel, Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision

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

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

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

Cookies von Drittanbietern

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

Cookies in der Anfrage können auch in normalen Cookies-von-Drittanbietern-Richtlinien unterdrückt werden. Die durchgesetzte Cookie-Richtlinie kann daher die in diesem Kapitel beschriebene Fähigkeit aufheben, was Sie daran hindert, überhaupt Anfragen mit Anmeldeinformationen zu stellen.

Die Cookie-Richtlinie rund um das SameSite-Attribut würde gelten.

Dieser Abschnitt listet die HTTP-Antwort-Header auf, die Server für Zugriffssteuerungsanfragen gemäß der Cross-Origin Resource Sharing-Spezifikation zurückgeben. Der vorherige Abschnitt gibt einen Überblick, wie diese in Aktion verwendet werden.

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

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

Access-Control-Allow-Origin gibt entweder einen einzelnen Ursprung an, der Browsern erlaubt, diesen Ursprung den Zugriff auf die Ressource zu gestatten; oder — bei Anfragen ohne Anmeldedaten — das *-Wildcard, das Browsern erlaubt, jedem Ursprung den Zugriff auf die Ressource zu gestatten.

Zum Beispiel, um dem Code vom Ursprung https://mozilla.org zu erlauben, auf die Ressource zuzugreifen, können Sie angeben:

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

Wenn der Server einen einzelnen Ursprung angibt (der basierend auf dem anfordernden Ursprung als Teil einer Erlaubnisliste dynamisch geändert werden kann) anstelle des *-Wildcards, sollte der Server auch Origin im Vary-Antwort-Header aufnehmen, um den Clients anzuzeigen, dass Serverantworten je nach Wert des Origin-Anforderungs-Headers unterschiedlich sein werden.

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

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

Zum Beispiel, folgendes würde den Zugriff auf die Header X-My-Custom-Header und X-Another-Custom-Header für den Browser erlauben:

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

Der Access-Control-Max-Age-Header gibt an, wie lange die Ergebnisse einer Preflight-Anfrage zwischengespeichert werden können. Für ein Beispiel einer Preflight-Anfrage siehe die obigen Beispiele.

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

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

Der Access-Control-Allow-Credentials-Header gibt 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, zeigt dieser an, ob die eigentliche Anfrage mit Anmeldedaten gemacht werden kann. Beachten Sie, dass einfache GET-Anfragen nicht vorab geprüft werden und wenn daher eine Anfrage für eine Ressource mit Anmeldedaten gemacht wird und dieser Header nicht mit der Ressource zurückgegeben wird, die Antwort vom Browser ignoriert wird und nicht an Web-Inhalte zurückgegeben wird.

Access-Control-Allow-Credentials: true

Anfragen mit Anmeldeinformationen werden oben diskutiert.

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 vorab überprüft wird, werden oben diskutiert.

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

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

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

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

Dieser Abschnitt listet Header auf, die Clients verwenden können, wenn sie HTTP-Anfragen stellen, um die Cross-Origin-Sharing-Funktion zu nutzen. Beachten Sie, dass diese Header für Sie gesetzt werden, wenn Serveraufrufe 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. Sie enthält keine Pfadangaben, nur den Servernamen.

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

Der Access-Control-Request-Method wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Methode verwendet wird, wenn die eigentliche Anfrage gestellt wird.

Access-Control-Request-Method: <method>

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

Der Access-Control-Request-Headers-Header wird verwendet, wenn eine Preflight-Anfrage gestellt wird, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die eigentliche Anfrage gestellt wird (zum Beispiel, indem sie als headers Option übergeben werden). Dieser browserseitige Header wird durch den entsprechenden serverseitigen Header von Access-Control-Allow-Headers beantwortet.

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

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

• CORS-Fehler
• CORS aktivieren: 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
• Die Verwendung von CORS mit allen (modernen) Browsern
• Stack Overflow-Antwort mit "Anleitung"-Informationen zum Umgang mit häufigen Problemen:
  • Wie man die CORS-Preflight vermeidet
  • Wie man einen CORS-Proxy verwendet, um "No Access-Control-Allow-Origin header" zu umgehen
  • Wie man "Access-Control-Allow-Origin header must not be the wildcard" behebt