Cross-Origin Resource Sharing (CORS) ist ein aufHTTP-Header basierender Mechanismus, der es einem Server ermöglicht, anzugeben, welcheUrsprünge (Domain, Schema oder Port) außer seinem eigenen ein Browser das Laden von Ressourcen erlauben soll. CORS beruht auch auf einem Mechanismus, bei dem Browser eine "Preflight"-Anfrage an den Server stellen, der die cross-origin Ressource hostet, um zu überprüfen, ob der Server die eigentliche Anfrage zulässt. Bei diesem Preflight sendet der Browser Header, die die HTTP-Methode und die Header angeben, die in der tatsächlichen Anfrage verwendet werden.

Ein Beispiel für eine Cross-Origin-Anfrage: Der im Frontend bereitgestellte JavaScript-Code vonhttps://domain-a.com verwendetfetch(), um eine Anfrage fürhttps://domain-b.com/data.json zu stellen.

Aus Sicherheitsgründen beschränken Browser Cross-Origin-HTTP-Anfragen, die von Skripten initiiert werden. Beispielsweise folgenfetch() undXMLHttpRequest derSame-Origin-Policy. Das bedeutet, dass eine Webanwendung, die diese APIs verwendet, nur Ressourcen von demselben Ursprung anfordern kann, von dem die Anwendung geladen wurde, es sei denn, die Antwort von anderen Ursprüngen enthält die richtigen CORS-Header.

Der CORS-Mechanismus unterstützt sichere Cross-Origin-Anfragen und Datentransfers zwischen Browsern und Servern. Browser verwenden CORS in APIs wiefetch() oderXMLHttpRequest, um die Risiken von Cross-Origin-HTTP-Anfragen zu mindern.

Welche Anfragen verwenden CORS?

DieserCross-Origin-Sharing-Standard kann Cross-Origin-HTTP-Anfragen für Folgendes ermöglichen:

• Aufrufe vonfetch() oderXMLHttpRequest, wie oben beschrieben.
• Web-Schriften (für die Verwendung von Schriften über Domains hinweg in@font-face innerhalb von CSS), wie in denSchriftanforderungen beim Abrufen beschrieben, damit Server TrueType-Schriften bereitstellen können, die nur über das Cross-Origin geladen und von Websites verwendet werden können, die dazu berechtigt sind.
• WebGL-Texturen.
• Bilder/Video-Frames, die mitdrawImage() auf eine Leinwand gezeichnet werden.
• CSS-Formen aus Bildern.

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

Funktionaler Überblick

Der Cross-Origin Resource Sharing-Standard funktioniert, indem er neueHTTP-Header hinzufügt, die es Servern ermöglichen, anzugeben, welche Ursprünge berechtigt sind, diese Informationen aus einem Webbrowser zu lesen. Zusätzlich zu HTTP-Anfragemethoden, die Nebenwirkungen auf Serverdaten verursachen können (insbesondere HTTP-Methoden außerGET, oderPOST mit bestimmtenMIME-Typen), verlangt die Spezifikation, dass Browser die Anfrage "vorab überprüfen" und unterstützte Methoden vom Server mit der HTTP-MethodeOPTIONS anfordern und dann, nach "Genehmigung" durch den Server, die eigentliche Anfrage senden. Server können Kunden auch mitteilen, ob "Anmeldeinformationen" (wieCookies undHTTP-Authentifizierung) mit Anfragen gesendet werden sollen.

CORS-Fehler führen zu Fehlern, aber aus Sicherheitsgründen sind Einzelheiten zu dem FehlerJavaScript nicht verfügbar. Der einzige verfügbare Hinweis besteht darin, dass ein Fehler aufgetreten ist. Die einzige Möglichkeit zur Bestimmung, was genau schiefgelaufen ist, besteht darin, die Konsole des Browsers nach Details zu durchsuchen.

Die nachfolgenden Abschnitte diskutieren Szenarien und bieten eine Übersicht der verwendeten HTTP-Header.

Beispiele für Zugriffskontrollszenarien

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

Einfache Anfragen

Einige Anfragen lösen keineCORS-Preflight aus. Diese werdeneinfache Anfragen genannt gemäß der veraltetenCORS-Spezifikation, obwohl dieFetch-Spezifikation (die CORS jetzt definiert) diesen Begriff nicht verwendet.

Der Grund dafür ist, dass das<form>-Element von HTML 4.0 (das vor cross-sitefetch() undXMLHttpRequest war) einfache Anfragen an jeden Ursprung senden kann, sodass jeder, der einen Server schreibt, bereits gegenCross-Site Request Forgery (CSRF) geschützt sein muss. Angesichts dieser Annahme muss der Server nicht extra zustimmen (indem er auf eine Preflight-Anfrage antwortet), um Anfragen zu erhalten, die wie Formularübermittlungen aussehen, da die CSRF-Bedrohung nicht schlimmer ist als die einer Formularübermittlung. Allerdings muss der Server immer noch mitAccess-Control-Allow-Origin zustimmen, um die Antwort mit dem Skriptzu teilen.

Eineeinfache Anfrage ist eine, diealle folgenden Bedingungen erfüllt:

• Eine der erlaubten Methoden:

  • GET
  • HEAD
  • POST

• Abgesehen von den Headern, die automatisch vom User-Agent gesetzt werden (z. B.Connection,User-Agent oder denverbotenen Anforderungsheadern), sind die einzigen Header, die manuell gesetzt werden dürfen, dieCORS-gesicherten Anfrageheader, die sind:

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

• Die einzigen Typ-/Subtype-Kombinationen, die für denMedientyp imContent-Type-Header erlaubt sind, sind:

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

• Falls die Anfrage unter Verwendung vonXMLHttpRequest gemacht wird, sind keine Ereignis-Listener auf dem Objekt registriert, das von derXMLHttpRequest.upload-Eigenschaft verwendet wird; das heißt, bei einer Instanz vonXMLHttpRequestxhr hat kein Codexhr.upload.addEventListener() aufgerufen, um einen Event-Listener hinzuzufügen, der den Upload überwacht.

• KeinReadableStream-Objekt wird in der Anfrage verwendet.

Zum Beispiel möchte der Webinhalt aufhttps://foo.example JSON-Inhalt von der Domainhttps://bar.other abrufen. Ein solcher Code könnte in JavaScript bereitgestellt werden, das auffoo.example läuft:

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 zum Einsatz kommen, um die Berechtigungen zu verwalten:

Schauen wir uns an, was der Browser in diesem Fall an den Server senden würde:

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

Der bemerkenswerte Header der Anfrage istOrigin, der zeigt, dass der Aufruf vonhttps://foo.example kommt.

Nun sehen wir uns die Antwort des Servers an:

HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 00:23:53 GMTServer: Apache/2Access-Control-Allow-Origin: *Keep-Alive: timeout=2, max=100Connection: Keep-AliveTransfer-Encoding: chunkedContent-Type: application/xml[…XML Data…]

Der Server antwortet mit einemAccess-Control-Allow-Origin-Header mitAccess-Control-Allow-Origin: *, was bedeutet, dass die Ressource vonjedem Ursprung aus zugänglich ist.

Access-Control-Allow-Origin: *

Dieses Muster desOrigin- undAccess-Control-Allow-Origin-Headers ist die einfachste Verwendung des Zugriffskontrollprotokolls. Wenn die Ressourcenbesitzer beihttps://bar.other den Zugriff auf die Ressource auf Anfragennur vonhttps://foo.example beschränken wollten (d.h. keine andere Domain alshttps://foo.example kann auf die Ressource in einer Cross-Origin-Weise zugreifen), würden sie senden:

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

Preflighted-Anfragen

Im Gegensatz zueinfachen Anfragen sendet der Browser bei "preflighted" Anfragen zuerst eine HTTP-Anfrage mit derOPTIONS-Methode an die Ressource auf dem anderen Ursprung, um festzustellen, ob die eigentliche Anfrage sicher gesendet werden kann. Solche Cross-Origin-Anfragen werden überprüft, da sie Auswirkungen auf Benutzerdaten haben können.

Das folgende ist ein Beispiel für eine Anfrage, die ü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 derPOST-Anfrage gesendet werden soll. Außerdem wird ein nicht-standardmäßigerX-PINGOTHER-HTTP-Anforderungsheader gesetzt. Solche Header sind nicht Teil von HTTP/1.1, aber im Allgemeinen für Webanwendungen nützlich. Da die Anfrage einenContent-Type vontext/xml verwendet, und da ein benutzerdefinierter Header gesetzt wird, wird diese Anfrage überprüft.

Schauen wir uns den vollständigen Austausch zwischen Client und Server an. Der erste Austausch ist diePreflight-Anfrage/Antwort:

OPTIONS /doc HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveOrigin: https://foo.exampleAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: content-type,x-pingotherHTTP/1.1 204 No ContentDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2Access-Control-Allow-Origin: https://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400Vary: Accept-Encoding, OriginKeep-Alive: timeout=2, max=100Connection: Keep-Alive

Der erste Block oben stellt die Preflight-Anfrage mit derOPTIONS-Methode dar. Der Browser ermittelt, dass er dies basierend auf den Anfrageparametern senden muss, die im JavaScript-Code-Snippet oben verwendet wurden, damit der Server antworten kann, ob es akzeptabel ist, die Anfrage mit den eigentlichen Anfrageparametern zu senden. OPTIONS ist eine HTTP/1.1-Methode, die verwendet wird, um weitere Informationen von Servern zu erhalten, und ist einesichere Methode, was bedeutet, dass sie nicht zum Ändern der Ressource verwendet werden kann. Beachten Sie, dass zusammen mit der OPTIONS-Anfrage zwei andere Anfrageheader gesendet werden:

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

DerAccess-Control-Request-Method-Header teilt dem Server im Rahmen einer Preflight-Anfrage mit, dass, wenn die eigentliche Anfrage gesendet wird, dies mit einerPOST-Anforderungsmethode erfolgt. DerAccess-Control-Request-Headers-Header teilt dem Server mit, dass, wenn die eigentliche Anfrage gesendet wird, dies mitX-PINGOTHER undContent-Type benutzerdefinierten Headern erfolgt. Jetzt 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, die angibt, dass die Anforderungsmethode (POST) und die Anforderungsheader (X-PINGOTHER) akzeptabel sind. Lassen Sie uns einen genaueren Blick auf die folgenden Zeilen werfen:

Access-Control-Allow-Origin: https://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400

Der Server antwortet mitAccess-Control-Allow-Origin: https://foo.example, wodurch der Zugriff nur auf die anfordernde Ursprungsdomain beschränkt wird. Er antwortet auch mitAccess-Control-Allow-Methods, was besagt, dassPOST undGET gültige Methoden sind, um die betreffende Ressource abzufragen (dieser Header ist demAllow-Antwortheader ähnlich, wird jedoch streng im Kontext der Zugriffskontrolle verwendet).

Der Server sendet auchAccess-Control-Allow-Headers mit einem Wert vonX-PINGOTHER, Content-Type, was bestätigt, dass diese Header verwendet werden dürfen, um die eigentliche Anfrage zu stellen. WieAccess-Control-Allow-Methods istAccess-Control-Allow-Headers eine durch Kommas getrennte Liste akzeptabler Header.

Schließlich gibtAccess-Control-Max-Age den Wert in Sekunden an, wie lange die Antwort auf die Preflight-Anfrage im Cache gehalten werden kann, ohne eine weitere Preflight-Anfrage zu senden. Der Standardwert beträgt 5 Sekunden. Im vorliegenden Fall beträgt das maximale Alter 86400 Sekunden (= 24 Stunden). Beachten Sie, dass jeder Browser einenmaximalen internen Wert hat, der Vorrang hat, wenn dieAccess-Control-Max-Age ihn übersteigt.

Sobald die Preflight-Anfrage abgeschlossen ist, wird die eigentliche Anfrage gesendet:

POST /doc HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveX-PINGOTHER: pingpongContent-Type: text/xml; charset=UTF-8Referer: https://foo.example/examples/preflightInvocation.htmlContent-Length: 55Origin: https://foo.examplePragma: no-cacheCache-Control: no-cache<person><name>Arun</name></person>HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:40 GMTServer: Apache/2Access-Control-Allow-Origin: https://foo.exampleVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 235Keep-Alive: timeout=2, max=99Connection: Keep-AliveContent-Type: text/plain[Some XML content]

Preflighted-Anfragen und Weiterleitungen

Nicht alle Browser unterstützen derzeit das Folgen von Redirects nach einer Preflighted-Anfrage. Wenn nach einer solchen Anfrage eine Weiterleitung erfolgt, melden einige Browser derzeit eine Fehlermeldung wie die folgende:

Die Anfrage wurde zuhttps://example.com/foo umgeleitet, was bei cross-origin-Anfragen, die Preflight erfordern, nicht erlaubt ist.Die Anfrage erfordert Preflight, was nicht erlaubt ist, um Cross-Origin-Redirects zu folgen.

Das CORS-Protokoll hat ursprünglich dieses Verhalten erfordert, wurde jedochanschließend geändert, um es nicht mehr zu benötigen. Allerdings haben nicht alle Browser die Änderung implementiert und zeigen daher immer noch das ursprünglich erforderte Verhalten.

Bis die Browser die Spezifikation übernehmen, könnten Sie in der Lage sein, diese Einschränkung zu umgehen, indem Sie eine oder mehrere 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, sodass sie eineeinfache Anfrage ist, die kein Preflight auslöst

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

1. Machen Sie eineeinfache Anfrage (unter Verwendung vonResponse.url für die Fetch API oderXMLHttpRequest.responseURL), um festzustellen, welche URL die eigentliche Preflighted-Anfrage erreichen würde.
2. Machen Sie eine weitere Anfrage (dieeigentliche Anfrage) unter Verwendung der URL, die Sie ausResponse.url oderXMLHttpRequest.responseURL im ersten Schritt erhalten haben.

Wenn die Anfrage eine ist, die wegen des Vorhandenseins desAuthorization-Headers in der Anfrage ein Preflight auslöst, können Sie die Einschränkung jedoch nicht mit den obigen Schritten umgehen. Und Sie werden sie überhaupt nicht umgehen können, es sei denn, Sie haben die Kontrolle über den Server, an den die Anfrage gestellt wird.

Anfragen mit Anmeldeinformationen

Das interessanteste Merkmal, das sowohl vonfetch() als auch vonXMLHttpRequest und CORS freigelegt wird, ist die Fähigkeit, "credentialed" Anfragen zu stellen, die sich der Informationen überHTTP-Cookies und die HTTP-Authentifizierung bewusst sind. Standardmäßig senden Browser bei Cross-Originfetch()- oderXMLHttpRequest-Aufrufenkeine Anmeldeinformationen.

Um einefetch()-Anfrage zu stellen, die Anmeldeinformationen einbezieht, setzen Sie die Optioncredentials auf"include".

Um eineXMLHttpRequest-Anfrage zu stellen, die Anmeldeinformationen einbezieht, setzen Sie die EigenschaftXMLHttpRequest.withCredentials auftrue.

In diesem Beispiel macht der ursprünglich vonhttps://foo.example geladene Inhalt eine GET-Anfrage an eine Ressource aufhttps://bar.other, die Cookies setzt. Inhalt auf foo.example könnte JavaScript wie folgt 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 einRequest-Objekt und setzt diecredentials-Option im Konstruktor auf"include", um diese Anfrage dann infetch() einzusetzen. Da es sich um eine einfacheGET-Anfrage handelt, wird sie nicht vorübergeprüft, aber der Browser wirdjede Antwort ablehnen, die nicht dasAccess-Control-Allow-Credentials-Header mit dem Werttrue enthält, und die Antwortnicht dem aufrufenden Webinhalt zur Verfügung stellen.

Hier ist ein Beispielaustausch zwischen Client und Server:

GET /resources/credentialed-content/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:71.0) Gecko/20100101 Firefox/71.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveReferer: https://foo.example/examples/credential.htmlOrigin: https://foo.exampleCookie: pageAccess=2HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:34:52 GMTServer: Apache/2Access-Control-Allow-Origin: https://foo.exampleAccess-Control-Allow-Credentials: trueCache-Control: no-cachePragma: no-cacheSet-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMTVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 106Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-Type: text/plain[text/plain content]

Obwohl derCookie-Header der Anfrage das Cookie enthält, das für den Inhalt aufhttps://bar.other vorgesehen ist, würde die Antwort ohneAccess-Control-Allow-Credentials mit dem Werttrue, wie in diesem Beispiel gezeigt, von der Antwort ignoriert und nicht dem Webinhalt zur Verfügung gestellt.

Preflight-Anfragen und Anmeldeinformationen

CORS-Preflight-Anfragen dürfen niemals Anmeldeinformationen enthalten. DieAntwort auf eine Preflight-Anfrage mussAccess-Control-Allow-Credentials: true angeben, um anzuzeigen, dass die eigentliche Anfrage mit Anmeldeinformationen gestellt werden kann.

Anfragen mit Anmeldeinformationen und Platzhalter

Bei der Beantwortung einer Anfrage mit Anmeldeinformationen:

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

Wenn eine Anfrage eine Anmeldeinformation (meist einenCookie-Header) enthält und die Antwort einenAccess-Control-Allow-Origin: * Header enthält (d.h. mit dem Platzhalter), blockiert der Browser den Zugriff auf die Antwort und meldet einen CORS-Fehler in der Developer-Konsole.

Wenn jedoch eine Anfrage eine Anmeldeinformation enthält (wie denCookie-Header) und die Antwort einen tatsächlichen Ursprung anstelle des Platzhalters enthält (zum BeispielAccess-Control-Allow-Origin: https://example.com), lässt der Browser den Zugriff auf die Antwort von dem angegebenen Ursprung zu.

Beachten Sie auch, dass jedwedemSet-Cookie-Header in einer Antwort kein Cookie gesetzt wird, wenn derAccess-Control-Allow-Origin-Wert in dieser Antwort der*-Platzhalter ist, anstatt eines tatsächlichen Ursprungs.

Drittanbieter-Cookies

Beachten Sie, dass Cookies, die in CORS-Antworten gesetzt werden, normalen Richtlinien für Drittanbieter-Cookies unterliegen. Im obigen Beispiel wird die Seite vonfoo.example geladen, aber derSet-Cookie-Header in der Antwort wird vonbar.other gesendet und würde somit nicht gespeichert werden, wenn der Browser des Benutzers so konfiguriert ist, dass er alle Drittanbieter-Cookies ablehnt.

Cookies, die in CORS-Anfragen und -Antworten gesetzt werden, unterliegen normalen Drittanbieter-Cookie-Richtlinien.

Richtlinien für Drittanbieter-Cookies können verhindern, dass Drittanbieter-Cookies in Anfragen gesendet werden, was effektiv eine Seite daran hindert, Anfragen mit Anmeldeinformationen zu stellen, auch wenn dies vom Drittanbieter-Server zugelassen ist (unter Verwendung vonAccess-Control-Allow-Credentials).Die Standardrichtlinie unterscheidet sich zwischen den Browsern, kann jedoch mit demSameSite-Attribut eingestellt werden.

Selbst wenn Anfragen mit Anmeldeinformationen zugelassen sind, kann ein Browser so konfiguriert sein, dass er alle Drittanbieter-Cookies in Antworten ablehnt.

Die HTTP-Antwortheader

Dieser Abschnitt listet die HTTP-Antwortheader auf, die Server für Zugriffskontrollanfragen zurückgeben, wie es von der Cross-Origin Resource Sharing-Spezifikation definiert ist. Der vorherige Abschnitt bietet eine Übersicht dieser in der Praxis.

Access-Control-Allow-Origin

Eine zurückgegebene Ressource kann einenAccess-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 Browsern erlaubt, diesen Ursprung die Ressource zugreifen zu lassen, oder — für Anfragenohne Anmeldeinformationen — sagt der*-Wildcard den Browsern, dass jeder Ursprung auf die Ressource zugreifen kann.

Zum Beispiel, um Code vom Ursprunghttps://mozilla.org den Zugriff auf die Ressource zu ermöglichen, können Sie angeben:

Access-Control-Allow-Origin: https://mozilla.orgVary: Origin

Wenn der Server einen einzelnen Ursprung angibt (der sich basierend auf dem anfordernden Ursprung als Teil einerAllowlist dynamisch ändern kann), anstelle des*-Wildcard, dann sollte der Server auchOrigin imVary-Antwortheader einschließen, um den Clients mitzuteilen, dass sich die Serverantworten basierend auf dem Wert desOrigin-Anfrageheaders unterscheiden.

Access-Control-Expose-Headers

DerAccess-Control-Expose-Headers-Header fügt die angegebenen Header der Allowlist hinzu, die JavaScript (wieResponse.headers) in Browsern zugreifen darf.

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

Zum Beispiel, das Folgende würde die HeaderX-My-Custom-Header undX-Another-Custom-Header für den Zugriff durch den Browser freigeben:

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

Access-Control-Max-Age

DerAccess-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>

Dasdelta-seconds-Parameter gibt die Anzahl von Sekunden an, für die die Ergebnisse zwischengespeichert werden können.

Access-Control-Allow-Credentials

DerAccess-Control-Allow-Credentials-Header gibt an, ob die Antwort auf die Anfrage offengelegt werden kann, wenn dascredentials-Flag wahr ist. Wenn es als Teil einer Antwort auf eine Preflight-Anfrage verwendet wird, gibt es an, ob die eigentliche Anfrage mit Anmeldeinformationen gemacht werden kann. Beachten Sie, dass einfacheGET-Anfragen nicht vorübergeprüft werden und daher, wenn eine Anfrage mit Anmeldeinformationen gestellt wird, wenn dieser Header nicht mit der Ressource zurückgegeben wird, die Antwort vom Browser ignoriert und nicht an den Webinhalt zurückgegeben wird.

Access-Control-Allow-Credentials: true

Anfragen mit Anmeldeinformationen werden oben diskutiert.

Access-Control-Allow-Methods

DerAccess-Control-Allow-Methods gibt die erlaubte Methode oder Methoden beim Zugriff auf die Ressource an. Dieser wird als Antwort auf eine Preflight-Anfrage verwendet. Die Bedingungen, unter denen eine Anfrage vorübergeprüft wird, werden oben diskutiert.

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

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

Access-Control-Allow-Headers

DerAccess-Control-Allow-Headers-Header wird als Antwort auf einePreflight-Anfrage verwendet, um anzuzeigen, welche HTTP-Header bei der eigentlichen Anfrage verwendet werden können. Dieser Header ist die serverseitige Antwort auf denAccess-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 Ausführen 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 Sie Anfragen an Server senden. Entwickler, die Cross-Origin-Anfragen stellen, müssen keine Cross-Origin-Sharing-Anfrageheader programmatisch setzen.

Origin

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

Origin: <origin>

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

Beachten Sie, dass bei jeder Zugriffskontrollanfrage derOrigin-Headerimmer gesendet wird.

Access-Control-Request-Method

DerAccess-Control-Request-Method wird beim Stellen einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Methode verwendet wird, wenn die eigentliche Anfrage gestellt wird.

Access-Control-Request-Method: <method>

Beispiele für diese Nutzung finden Sieoben.

Access-Control-Request-Headers

DerAccess-Control-Request-Headers-Header wird beim Stellen einer Preflight-Anfrage verwendet, um dem Server mitzuteilen, welche HTTP-Header verwendet werden, wenn die eigentliche Anfrage gestellt wird (zum Beispiel durch Übergabe alsheaders Option). Dieser Browser-seitige Header wird durch den komplementären server-seitigen Header vonAccess-Control-Allow-Headers beantwortet.

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

Beispiele für diese Nutzung finden Sieoben.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• 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 und -Generator
• Wie man Chrome ohne CORS ausführt
• CORS mit allen (modernen) Browsern verwenden
• Stack Overflow-Antwort mit "Anleitungen" für den Umgang mit allgemeinen Problemen:
  • Wie man den CORS-Preflight vermeidet
  • Wie man einen CORS-Proxy verwendet, um das Problem"Kein Access-Control-Allow-Origin-Header" zu umgehen
  • Wie man das Problem"Access-Control-Allow-Origin-Header darf nicht der Platzhalter sein" behebt