オリジン間リソース共有 (Cross-Origin Resource Sharing,CORS) は、HTTP ヘッダーベースの仕組みを使用して、あるオリジンで動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組みです。ウェブアプリケーションは、自分とは異なるオリジン (ドメイン、プロトコル、ポート番号) にあるリソースをリクエストするとき、オリジン間 HTTP リクエストを実行します。

オリジン間リクエストとは、例えばhttps://domain-a.com で提供されているウェブアプリケーションのフロントエンド JavaScript コードがfetch() を使用してhttps://domain-b.com/data.json へリクエストを行うようなものです。

セキュリティ上の理由から、ブラウザーは、スクリプトによって開始されるオリジン間 HTTP リクエストを制限しています。例えば、fetch() やXMLHttpRequest は同一オリジンポリシー (same-origin policy) に従います。つまり、これらの API を使用するウェブアプリケーションは、そのアプリケーションが読み込まれたのと同じオリジンに対してのみリソースのリクエストを行うことができ、それ以外のオリジンからの場合は正しい CORS ヘッダーを含んでいることが必要です。

CORS の仕組みは、安全なオリジン間のリクエストとブラウザー・サーバー間のデータ転送を支援します。最近のブラウザーは CORS をfetch() やXMLHttpRequest などの API で使用して、オリジン間 HTTP リクエストのリスクの緩和に役立てています。

CORS を使用したリクエストとは

このcross-origin sharing standard では、以下についてオリジン間の HTTP リクエストができるようにしています。

• 前述のようなfetch() やXMLHttpRequest の呼び出し。
• ウェブフォント（CSS の@font-face で別ドメインのフォントを利用するため）。これによりサーバーは、許可したウェブサイトのみからオリジンをまたがって読み込んで利用できる TrueType フォントを提供することができます。
• WebGL テクスチャ。
• drawImage() を使用してキャンバスへ描かれた画像や映像のフレーム
• 画像から生成する CSS シェイプ。

この記事では、 HTTP ヘッダーの要件を含むオリジン間リソース共有の全般的な説明を行います。

機能概要

オリジン間リソース共有の仕様は、新たなHTTP ヘッダーを追加して、あるウェブブラウザーから情報を読み取ることを許可されているオリジンをサーバーが記述することで作用します。加えて、サーバーのデータに副作用を引き起こす可能性がある HTTP のリクエストメソッド（特にGET 以外の HTTP メソッドや、特定のMIME タイプを持つPOST）のために、仕様書では、ブラウザーがあらかじめリクエストの「プリフライト」（サーバーから対応するメソッドの一覧を収集すること）を HTTP のOPTIONS リクエストメソッドを用いて行い、サーバーの「認可」のもとに実際のリクエストを送信することを指示しています。サーバーはリクエスト時に「資格情報」（Cookie やHTTP 認証など）を送信するべきかをクライアントに伝えることもできます。

CORS は様々なエラーで失敗することがありますが、セキュリティ上の理由から、エラーについて JavaScript から知ることができないよう定められています。コードからはエラーが発生したということしか分かりません。何が悪かったのかを具体的に知ることができる唯一の方法は、ブラウザーのコンソールで詳細を見ることです。

以降の節ではシナリオの説明に加え、 HTTP ヘッダーの使い方の詳細も提供します。

アクセス制御シナリオの例

オリジン間リソース共有の動作の仕組みを説明する 3 つのシナリオを示します。これらの例はすべてfetch() を用いており、対応しているブラウザーにおいて、オリジンをまたいでアクセスすることができます。

単純リクエスト

リクエストによってはCORS プリフライトを発生させません。これをこの記事では古いCORS 仕様書に倣って「単純リクエスト」と呼んでいますが、（現在 CORS を定義している）Fetch 仕様書 ではこの用語を使用していません。

その動機は、HTML 4.0 からの<form> 要素（サイト間fetch() とXMLHttpRequest に先行する）は、どのオリジンにでも単純なリクエストを送信できるので、サーバーを書く人はすでにクロスサイトリクエストフォージェリー (CSRF) から保護していなければならないからです。この仮定の下では、 CSRF の脅威はフォーム送信の脅威よりも悪くないので、サーバーはフォーム送信のように見えるすべてのリクエストを受け取ることを（プリフライトリクエストに応答することによって）オプトインする必要はないのです。しかし、サーバーはAccess-Control-Allow-Origin を使用して、レスポンスをスクリプトと共有することを選択する必要があります。

単純リクエストは、以下のすべての条件を満たすものです。

• 許可されているメソッドのうちのいずれかであること。

  • GET
  • HEAD
  • POST

• ユーザーエージェントによって自動的に設定されるヘッダー（たとえばConnection やUser-Agent や禁止リクエストヘッダー）を除いて、CORS セーフリストリクエストヘッダーだけを手動で設定することができます。

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type （但し、下記の追加の要件に注意してください）
  • Range （単純範囲ヘッダー値、例えばbytes=256- やbytes=127-255 の場合）

• Content-Type ヘッダーで指定できるメディア種別に許されるタイプ/サブタイプの組み合わせは、以下のもののみです。

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

• XMLHttpRequest オブジェクトを使用してリクエストを行う場合は、XMLHttpRequest.upload プロパティから返されるオブジェクトにイベントリスナーが登録されていないこと。すなわち、XMLHttpRequest インスタンスをxhr とした場合、どのコードもxhr.upload.addEventListener() が呼び出してアップロードを監視するためのイベントリスナーを追加していないこと。

• リクエストにReadableStream オブジェクトが使用されていないこと。

例えば、https://foo.example のウェブコンテンツが JSON コンテンツをドメインhttps://bar.other から取得したいとします。 この種のコードは、foo.example で展開された JavaScript で使用される可能性があります。

const fetchPromise = fetch("https://bar.other");fetchPromise  .then((response) => response.json())  .then((data) => {    console.log(data);  });

この処理は、特権を扱うために CORS ヘッダーを使用して、クライアントとサーバーの間で簡単なデータ交換を行います。

この場合、ブラウザーがサーバーに何を送信し、サーバーが何を返すかを見てみましょう。

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

特筆すべきリクエストヘッダーはOrigin であり、呼び出しがhttps://foo.example から来たことを表します。

サーバーがどのように返答するかを見てみましょう。

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 データ…]

レスポンスでは、サーバーがAccess-Control-Allow-Origin ヘッダーをAccess-Control-Allow-Origin: * と返しており、そのリソースがすべてのドメインからアクセスできることを示しています。

Access-Control-Allow-Origin: *

Origin ヘッダーとAccess-Control-Allow-Origin ヘッダーのこのパターンは、アクセス制御プロトコルのもっとも簡単な使い方です。https://bar.other にあるリソースの所有者が、リソースへの制限をhttps://foo.example からのリクエストのみに制限したい（すなわち、https://foo.examle 以外のドメインがオリジン間の作法でリソースにアクセスを許可しない）と考えていた場合は、以下のように送信します。

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

プリフライトリクエスト

単純リクエストとは異なり、「プリフライト」リクエストは始めにOPTIONS メソッドによる HTTP リクエストを他のドメインにあるリソースに向けて送り、実際のリクエストを送信しても安全かどうかを確かめます。オリジン間リクエストがユーザーデータに影響を与える可能性があるような場合に、プリフライトを行います。

プリフライトが行われるリクエストの例です。

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);});

上記の例では、POST で送信する XML の本体を作成しています。また、標準外のX-PINGOTHER HTTP リクエストヘッダーを設定しています。このようなヘッダーは HTTP/1.1 プロトコルに含まれていませんが、ウェブアプリケーションでは一般的に便利なものです。リクエストでContent-Type にtext/xml を使用しており、かつ独自のヘッダーを設定しているため、このリクエストではプリフライトを行います。

クライアントとサーバーとの間のやりとりの全容を見てみましょう。最初のやり取りはプリフライトリクエスト/レスポンスです。

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

最初のブロックは、OPTIONS メソッドによるプリフライトリクエストを表します。ブラウザーは上記の JavaScript コードで使用していていたリクエストの引数に基づいて、プリフライトの送信が必要であることを判断します。これによりサーバーは実際のリクエストの引数によって送られるリクエストを受け入れ可能かを応答することができます。 OPTIONS は HTTP/1.1 のメソッドであり、サーバーから付加的な情報を得るために用いるもので、また安全なメソッド、つまりリソースを変更するためには使用できないメソッドです。 OPTIONS リクエストと合わせて、他にリクエストヘッダーを 2 つ送信していることに注意してください。

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

Access-Control-Request-Method ヘッダーは、プリフライトリクエストの一部として、実際のリクエストがPOST リクエストメソッドで行われることをサーバーに通知します。Access-Control-Request-Headers ヘッダーは、実際のリクエストにカスタムヘッダーであるX-PINGOTHER および Content-Type が含まれることをサーバーに通知します。ここでサーバーは、この状況下でリクエストの受け入れを望むかを判断する機会が与えられます。

上記の 2 番目のブロックはサーバーが返すレスポンスであり、リクエストメソッド (POST) とリクエストヘッダー (X-PINGOTHER) が受け入れられることを示しています。特に、次の行を見てみましょう。

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

サーバーはAccess-Control-Allow-Origin: https://foo.example により、アクセスをリクエストしているオリジンのドメインだけに限定することを返答しています。また、Access-Control-Allow-Methods を返しており、これは当該リソースへの問い合わせでPOST およびGET が有効なメソッドであることを伝えます（なお、このヘッダーはレスポンスヘッダーのAllow と似ていますが、アクセス制御でのみ使用されることに注意してください）。

またサーバーは、Access-Control-Allow-Headers をX-PINGOTHER, Content-Type の値で送信し、実際のリクエストで使用されるヘッダーを承認しています。Access-Control-Allow-Methods と同様に、Access-Control-Allow-Headers は受け入れ可能なヘッダーをカンマ区切りのリストで表します。

最後にAccess-Control-Max-Age は、プリフライトリクエストを再び送らなくてもいいように、プリフライトのレスポンスをキャッシュしてよい時間を秒数で与えます。既定値は 5 秒です。この例では 86400 秒（24 時間）です。なお、ブラウザーはそれぞれ内部的な上限値を持っており、Access-Control-Max-Age を超えた場合に制限を行います。

プリフライトリクエストが完了したら、実際のリクエストを送ります。

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[いくらかの XML コンテンツ]

プリフライトリクエストとリダイレクト

現在のところ、すべてのブラウザーが下記のようなプリフライトリクエストのリダイレクトに対応しているわけではありません。プリフライトリクエストにリダイレクトが発生すると、ブラウザーによっては以下のようなエラーメッセージを報告します。

The request was redirected tohttps://example.com/foo, which is disallowed for cross-origin requests that require preflight.Request requires preflight, which is disallowed to follow cross-origin redirects.

もともと CORS プロトコルはそのような動作を要求していましたが、その後で必要がないと変更されました。しかし、多くのブラウザーはまだ変更を実装していないため、もともと要求されていた動作に従っています。

ブラウザーが仕様に追いつくまで、以下の一方もしくは両方を行うことでこの制限を回避することができます。

• サーバー側の振る舞いを変更して、プリフライトが発生しないようにするか、リダイレクトが発生しないようにする
• リクエストをプリフライトを起こさない単純リクエストなどに変更する

これらの変更ができない場合は、次のような別な方法があります。

1. 単純リクエストを行い（フェッチ API のResponse.url またはXMLHttpRequest.responseURL を使用する）、実際のプリフライトリクエストが転送される先を特定する。
2. 最初のステップのResponse.url またはXMLHttpRequest.responseURL で得た URL を使用して、もう一つのリクエスト（「実際の」リクエスト）を行う。

ただし、リクエストにAuthorization ヘッダーが存在するためにプリフライトが発生するリクエストの場合、上記の手順を使用して制限を回避することはできません。リクエストが行われているサーバーを制御できない限り、まったく回避することはできません。

資格情報を含むリクエスト

fetch() またはXMLHttpRequest と CORS の両方によって明らかになる最も興味深い機能は、HTTP クッキーと HTTP 資格情報によってわかる「資格情報を含む」リクエストを作成することができることです。既定では、オリジン間のfetch() またはXMLHttpRequest の呼び出しにおいて、ブラウザーは資格情報を送信しません。

fetch() リクエストに資格情報を含めるようにするには、credentials オプションを"include" に設定してください。

XMLHttpRequest リクエストに資格情報を含めるようにするには、XMLHttpRequest.withCredentials プロパティをtrue に設定してください。

以下の例ではhttps://foo.example から読み込まれた元のコンテンツが、https://bar.other にあるリソースに対してクッキーを設定したシンプルな GET リクエストを行います。 foo.example のコンテンツは以下のような JavaScript を含んでいるかもしれません。

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));

このコードは、Request オブジェクトを作成し、コンストラクターでcredentials オプションを"include" に設定し、このリクエストをfetch() に渡します。これは単純なGET リクエストなのでプリフライトは行いませんが、ブラウザーはAccess-Control-Allow-Credentials: true ヘッダーを持たないレスポンスを拒否し、ウェブコンテンツを呼び出すレスポンスを作成しないでしょう。

以下はクライアントとサーバーとの間のやりとりの例です。

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 コンテンツ]

リクエストのCookie ヘッダーには、https://bar.other のコンテンツを対象とした Cookie が含まれていますが、この例で示されているように、 bar.other がAccess-Control-Allow-Credentials でtrue の値を返さなかった場合、レスポンスは無視され、ウェブコンテンツには利用できなくなります。

プリフライトリクエストと資格情報

CORS のプリフライトリクエストに資格情報を含めてはいけません。プリフライトリスクエストへのレスポンスにはAccess-Control-Allow-Credentials: true を指定して、実際のリクエストを資格情報付きで行うことができることを示す必要があります。

資格情報付きリクエストとワイルドカード

資格情報付きリクエストに返答する場合、

• サーバーはAccess-Control-Allow-Origin ヘッダーで* ワイルドカードを指定してはならず、Access-Control-Allow-Origin: https://example.com のように、明示的にオリジンを指定しなければなりません。
• サーバーはAccess-Control-Allow-Headers ヘッダーで* ワイルドカードを指定してはならず、Access-Control-Allow-Headers: X-PINGOTHER, Content-Type のように、明示的にヘッダー名を指定しなければなりません。
• サーバーはAccess-Control-Allow-Methods ヘッダーで* ワイルドカードを指定してはならず、Access-Control-Allow-Methods: POST, GET のように、明示的にメソッド名を指定しなければなりません。
• サーバーはAccess-Control-Expose-Headers ヘッダーで* ワイルドカードを指定してはならず、Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision のように、明示的にメソッド名を指定しなければなりません。

リクエストが資格情報（多くの場合はCookie ヘッダー）を含んでおり、そのレスポンスがAccess-Control-Allow-Origin: * ヘッダー（つまりワイルドカード）を含んでいる場合、ブラウザーはレスポンスへのアクセスをブロックし、開発ツールのコンソールに CORS エラーを報告します。

ただし、リクエストが（Cookie ヘッダーのような）資格情報を含んで行われ、そのレスポンスがワイルドカードではない実際のオリジンを含んでいる場合（例えばAccess-Control-Allow-Origin: https://example.com など）、ブラウザーは指定されたオリジンからのレスポンスへのアクセスを許可します。

また、レスポンス内のAccess-Control-Allow-Origin レスポンスヘッダーの値が実際のオリジンではなく* ワイルドカードであった場合、クッキーは設定されません。

サードパーティークッキー

CORS のレスポンスに設定されたクッキーは、サードパーティークッキーに関する通常のポリシーに従うことに注意してください。上記の例では、ページはfoo.example から読み込まれていますが、レスポンスのCookie ヘッダーはbar.other から送られているので、ユーザーのブラウザーがサードパーティークッキーをすべて拒否するよう設定されていた場合は保存されません。

リクエスト中のクッキーは、通常のサードパーティクッキーポリシーでも抑制されることがあります。したがって、クッキーポリシーが強制されていると、この章で説明されている機能が無効になり、事実上、認証されたリクエストを行うことができなくなるかもしれません。

SameSite 属性に関するクッキーポリシーは適用されます。

HTTP レスポンスヘッダー

この節では、オリジン間リソース共有の仕様書で定義されている、アクセス制御のためにサーバーが返す HTTP レスポンスヘッダーを掲載します。これらの実際の動作の概要についての説明は、前の節をご覧ください。

Access-Control-Allow-Origin

返却されるリソースには、以下のような構文で 1 つのAccess-Control-Allow-Origin ヘッダーがつくことがあります。

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

Access-Control-Allow-Origin は、リソースへのアクセスを許可するオリジンをブラウザーに伝えるための単一のオリジン、または — 資格情報を含まないリクエストにおいては — どのオリジンにもリソースへのアクセスを許可することをブラウザーに伝えるワイルドカード* のどちらかを指定することができます。

例えば、https://mozilla.org のオリジンからのコードにリソースへのアクセスを許可するには、次のように指定します。

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

サーバーがワイルドカード* ではなく（許可リストの一部としてリクエストするオリジンに基づいて動的に変更される可能性がある）単一のオリジンを指定した場合は、サーバーはOrigin をVary レスポンスヘッダーに含めて、サーバーのレスポンスがOrigin リクエストヘッダーの値によって変化することもクライアントに示してください。

Access-Control-Expose-Headers

Access-Control-Expose-Headers ヘッダーは、指定されたヘッダーをブラウザー内の JavaScript（Response.headers など）からアクセスできる許可リストに加えます。

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

例えば、以下のようになります。

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

これは、ブラウザーに対してX-My-Custom-Header およびX-Another-Custom-Header ヘッダーを許可します。

Access-Control-Max-Age

このヘッダーはプリフライトリクエストの結果をキャッシュしてよい時間を示します。プリフライトリクエストの例は、前出の例をご覧ください。

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

delta-seconds 引数は、結果をキャッシュしてよい時間を秒単位で示します。

Access-Control-Allow-Credentials

Access-Control-Allow-Credentials はcredentials フラグが true である場合に、リクエストへのレスポンスを開示してよいか否かを示します。プリフライトリクエストのレスポンスの一部として用いられたときは、実際のリクエストで資格情報を使用してよいか否かを示します。単純なGET リクエストはプリフライトを行いませんので、リソースへのリクエストが資格情報付きで行われた場合にリソースと共にこのヘッダーを返さなければ、ブラウザーがそのレスポンスを無視し、ウェブのコンテンツが返されないことに注意してください。

Access-Control-Allow-Credentials: true

資格情報付きリクエストは前に説明したとおりです。

Access-Control-Allow-Methods

Access-Control-Allow-Methods ヘッダーは、リソースへのアクセス時に許可するメソッドを指定します。これはプリフライトリクエストのレスポンスで用いられます。リクエストのプリフライトを行う条件については前述のとおりです。

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

ブラウザーにこのヘッダーを送信する例を含む、プリフライトリクエストの例は前述のとおりです。

Access-Control-Allow-Headers

Access-Control-Allow-Headers ヘッダーはプリフライトリクエストへのレスポンスで使用され、実際のリクエストを行う際に使用される HTTP ヘッダーを示します。このヘッダーはブラウザーのAccess-Control-Request-Headers ヘッダーに対するサーバー側のレスポンスです。

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

HTTP リクエストヘッダー

この節では、 HTTP リクエストを発行する際、オリジン間リソース共有機能を利用するためにクライアントが使用できるヘッダーの一覧を掲載します。なお、これらのヘッダーはサーバーの呼び出し時に設定されます。オリジン間リクエストを作成する開発者は、オリジン間共有リクエストヘッダーをプログラムで設定する必要はありません。

Origin

Origin ヘッダーはオリジン間のアクセスリクエストやプリフライトリクエストのオリジンを示します。

Origin: <origin>

origin は、リクエストを開始したサーバーを示す URL です。ここにパス情報は含めず、サーバー名だけにします。

なお、すべてのアクセス制御リクエストにおいて、Origin ヘッダーは常に送信されます。

Access-Control-Request-Method

Access-Control-Request-Method はプリフライトリクエストを発信する際に、実際のリクエストを行う際に使用する HTTP メソッドをサーバーに知らせるために使用します。

Access-Control-Request-Method: <method>

使用例は前述のとおりです。

Access-Control-Request-Headers

Access-Control-Request-Headers ヘッダーは、プリフライトリクエストを発行する際に、実際のリクエストを行う際に（例えば、headers オプションとして渡すことで）使用する HTTP ヘッダーをサーバーに知らせるために使用します。このブラウザー側のヘッダーは、サーバー側のヘッダーAccess-Control-Allow-Headers によって回答されます。

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

使用例は前述のとおりです。

仕様書

ブラウザーの互換性

関連情報

• CORS のエラー
• CORS の有効化: CORS 対応をサーバーに追加したい（英語）
• フェッチ API
• XMLHttpRequest
• Will it CORS? - 対話型の CORS の説明および生成（英語）
• Chrome ブラウザーを CORS なしで実行する方法（英語）
• すべての（現代の）ブラウザーで CORS を使用（英語）
• Stack Overflow のよくある問題を解決するための "how to" 情報（英語）:
  • CORS のプリフライトを防止する方法
  • CORS プロキシーを使用して「Access-Control-Allow-Origin ヘッダーの欠落」を回避する方法
  • 「Access-Control-Allow-Origin ヘッダーがワイルドカードを扱えない」ことを修正する方法