オリジン間リソース共有 (CORS)

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

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

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

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

この記事を読むべき人

誰もが読むべきです。

もっと具体的に言えば、この記事はウェブ管理者サーバー開発者フロントエンド開発者向けです。最近のブラウザーはヘッダーやポリシーの強制を含む、オリジン間共有のクライアント側コンポーネントを扱います。しかし CORS 標準は、サーバーが新たなリクエストヘッダーやレスポンスヘッダーを扱わなければならないことを示しています。

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

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

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

機能概要

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

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

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

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

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

単純リクエスト

リクエストによっては CORS プリフライトを発生させません。これをこの記事では単純リクエストと呼んでいますが、 (CORS を定義している) Fetch 仕様書ではこの用語を使用していません。単純リクエストは、以下のすべての条件を満たすものです。

Note: WebKit Nightly および Safari Technology Preview は、 AcceptAccept-LanguageContent-Language ヘッダーの値に追加の制限を掛けています。これらのヘッダーが「標準外」の値の場合、 WebKit/Safari はそのリクエストが「単純リクエスト」の条件に合うとは判断しません。 WebKit/Safari がこれらのヘッダーのどの値を「標準外」と判断するかについては、以下の WebKit のバグを除いて文書化されていません。

これは仕様の一部ではないので、他のブラウザーはこの追加の制限を実装していません。

例えば、ドメイン https://foo.example にあるウェブコンテンツがドメイン https://bar.other にあるコンテンツを呼び出したいとします。以下のようなコードが foo.example 内の JavaScript で使用されるかもしれません。

const xhr = new XMLHttpRequest();
const url = 'https://bar.other/resources/public-data/';

xhr.open('GET', url);
xhr.onreadystatechange = someHandler;
xhr.send();

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

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

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

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

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

レスポンスでは、サーバーが 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

Note: 資格情報を含むリクエストに応答する場合、サーバーは Access-Control-Allow-Origin ヘッダーにオリジンを値として指定する必要があり、"*" ワイルドカードを指定することはできません。

プリフライトリクエスト

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

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

const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

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

Note: 後述するように、実際の POST リクエストでは Access-Control-Request-* ヘッダーを含みません。OPTIONS リクエストのみで必要になります。

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

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: X-PINGOTHER, Content-Type

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

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

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

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

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

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

サーバーは 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 は、プリフライトリクエストを再び送らなくてもいいように、プリフライトのレスポンスをキャッシュしてよい時間を秒数で与えます。この例では 86400 秒、つまり 24 時間です。なお、ブラウザーはそれぞれ内部的な上限値を持っており、 Access-Control-Max-Age が上回った場合に制限を行います。

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

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 payload]

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

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

The request was redirected to 'https://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. 単純リクエストを行い (Fetch API の Response.url (en-US) または XMLHttpRequest.responseURL を使用する)、実際のプリフライトリクエストが転送される先を特定する。
  2. 最初のステップの Response.url または XMLHttpRequest.responseURL で得た URL を使用して、もう一つのリクエスト (本当のリクエスト) を行う。

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

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

Note: 資格情報を含むリクエストを異なるドメインに行う場合、サードパーティクッキーポリシーも適用されます。このポリシーは、この章で説明しているように、サーバーやクライアントでの設定とは無関係に常に実施されます。

XMLHttpRequestFetch と CORS の両方によって明らかになる最も興味深い機能は、HTTP クッキーと HTTP 資格情報によってわかる「資格情報を含む」リクエストを作成することができることです。既定では、サイト間の XMLHttpRequest または Fetch の呼び出しにおいて、ブラウザーは資格情報を送信しませんXMLHttpRequest オブジェクトまたは Request のコンストラクターの呼び出し時に、特定のフラグを設定する必要があります。

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

const invocation = new XMLHttpRequest();
const url = 'https://bar.other/resources/credentialed-content/';

function callOtherDomain() {
  if (invocation) {
    invocation.open('GET', url, true);
    invocation.withCredentials = true;
    invocation.onreadystatechange = handler;
    invocation.send();
  }
}

7 行目で、クッキー付きで呼び出しを行うために XMLHttpRequest に設定する必要があるフラグ、 withCredentials という論理型の値を示しています。既定では、クッキーなしで呼び出しが行われます。これは単純な GET リクエストなのでプリフライトは行いませんが、ブラウザーは Access-Control-Allow-Credentials: true ヘッダーを持たないレスポンスを拒否し、ウェブコンテンツを呼び出すレスポンスを作成しないでしょう。

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

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 payload]

10 行目に https://bar.other 向けのクッキーが含まれていますが、bar.other が Access-Control-Allow-Credentials: true (17 行目) をレスポンスに含めなければ、レスポンスは無視されウェブコンテンツで使用できません。

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

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

Note: エンタープライズ認証サービスの中には、 Fetch 仕様書に反して、プリフライトリクエストで TLS クライアント証明書を送信することを要求するものがあります。

Firefox 87 では、network.cors_preflight.allow_client_certtrue に設定することで、この準拠していない動作を有効にすることができます。(バグ 1511151). Chromium ベースのブラウザーでは現在、CORS プリフライトリクエストで TLS クライアント証明書を常に送信します (Chrome bug 775438)。

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

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

  • サーバーは 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 のように、明示的にメソッド名を指定しなければなりません。

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

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

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

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

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

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

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.org
Vary: Origin

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

Access-Control-Expose-Headers

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

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

Origin

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

Origin: <origin>

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

Note: origin の値は null にすることができます。

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

Access-Control-Request-Method

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

Access-Control-Request-Method: <method>

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

Access-Control-Request-Headers

Access-Control-Request-Headers ヘッダーは、プリフライトリクエストを発行する際に、実際のリクエストを行う際に (setRequestHeader() などによって) 使用する HTTP ヘッダーをサーバーに知らせるために使用します。このブラウザー側のヘッダーは、サーバー側のヘッダー Access-Control-Allow-Headers によって回答されます。

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

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

仕様書

仕様書 状態 備考
Fetch
CORS の定義
現行の標準 W3C CORS 仕様書に代わる新しい定義です。

ブラウザーの互換性

BCD tables only load in the browser

関連情報