initial commit

17 files changed, 1212 insertions, 0 deletions

diff --git a/files/ja/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html b/files/ja/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html
new file mode 100644
index 0000000000..d8f2cfd87f
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsalloworiginnotmatchingorigin/index.html
@@ -0,0 +1,47 @@
+---
+title: 'Reason: CORS header ''Access-Control-Allow-Origin'' does not match ''xyz'''
+slug: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin
+tags:
+  - CORS
+  - CORSAllowOriginNotMatchingOrigin
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS header 'Access-Control-Allow-Origin' does not match 'xyz'</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>リクエストを作成しているオリジンが、 {{HTTPHeader("Access-Control-Allow-Origin")}} ヘッダーによって許可されたオリジンのいずれにも一致しないことを表します。</p>
+
+<p>このエラーは、レスポンスに複数の <code>Access-Control-Allow-Origin</code> ヘッダーが含まれていると発生することがあります。</p>
+
+<p>コードが CORS リクエストを使用してアクセスしているサービスが管理下にあるのであれば、 <code>Access-Control-Allow-Origin</code> ヘッダーがそのアクセス元が含むように構成されていること、及びそのヘッダーがレスポンス内に1つしか含まれていないことを確認してください。ヘッダー自体はコンマ区切りで複数のオリジンを受け付けるので、新しいオリジンを追加することは難しくはありません。</p>
+
+<p>例えば Apache では、サーバー構成 (の中の <code>&lt;Directory&gt;</code>, <code>&lt;Location&gt;</code>, <code>&lt;Files&gt;</code>, <code>&lt;VirtualHost&gt;</code> のうち適切な節) に次のような行を追加してください。構成はふつう、 <code>.conf</code> ファイル又は (一般的な名前は <code>httpd.conf</code> や <code>apache.conf</code>) 又は <code>.htaccess</code> ファイルにあります。</p>
+
+<pre>Header set Access-Control-Allow-Origin '<em>origin-list</em>'</pre>
+
+<p>Nginx では、このヘッダーを設定するコマンドは次の通りです。</p>
+
+<pre>add_header 'Access-Control-Allow-Origin' '<em>origin-list</em>'</pre>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsdidnotsucceed/index.html b/files/ja/web/http/cors/errors/corsdidnotsucceed/index.html
new file mode 100644
index 0000000000..a679f1e32b
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsdidnotsucceed/index.html
@@ -0,0 +1,46 @@
+---
+title: 'Reason: CORS request did not succeed'
+slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+tags:
+  - CORS
+  - CORSDidNotSccceed
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - クロスオリジン
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS request did not succeed</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何に失敗したか</h2>
+
+<p>CORS を使用した {{Glossary("HTTP")}} 要求が、ネットワークまたはプロトコルレベルで HTTP 接続に失敗したために失敗しました。エラーは CORS に直接関連したものではなく、ある種の基本的なネットワークエラーです。</p>
+
+<p>多くの場合、ブラウザーのプラグイン (例えば広告ブロッカーやプライバシー保護) がリクエストをブロックしたときに発生します。</p>
+
+<p>その他の可能性のある原因は以下の通りです。</p>
+
+<ul>
+ <li>無効な資格情報を用いて <code>https</code> のリソースにアクセスしようとすると、このエラーが発生します。</li>
+ <li><code>http</code> のリソースに <code>https</code> のオリジンのページからアクセスしようとした場合も、このエラーが発生します。</li>
+ <li>Firefox 68 では、 <code>https</code> のページが <code>http://localhost</code> へアクセスすることが禁止されていますが、これは <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1488740">Bug 1488740</a> で変更される可能性があります。</li>
+ <li>サーバーが ({{Glossary("Preflight request", "プリフライトリクエスト")}}に応答したのに) 実際のリクエストには応答しなかった場合。開発中の HTTP サービスが何もデータを返さずに異常停止した場合などが考えられます。</li>
+</ul>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsdisabled/index.html b/files/ja/web/http/cors/errors/corsdisabled/index.html
new file mode 100644
index 0000000000..c86d2c64c2
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsdisabled/index.html
@@ -0,0 +1,37 @@
+---
+title: 'Reason: CORS disabled'
+slug: Web/HTTP/CORS/Errors/CORSDisabled
+tags:
+  - CORS
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - リソース
+  - 共有
+  - 同一オリジン
+  - 無効
+translation_of: Web/HTTP/CORS/Errors/CORSDisabled
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS disabled</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何に失敗したか</h2>
+
+<p>{{Glossary("CORS")}} を使う必要がある要求が行われましたが、ユーザーのブラウザーで CORS が無効になっています。これが発生した場合、ブラウザーの CORS を有効に戻す必要があります。</p>
+
+<p>Firefox では、 CORS を無効にする設定は <code>content.cors.disable</code> です。これを <code>true</code> に設定すると CORS が無効になり、この場合は常に、 CORS 要求は常にこのエラーで失敗します。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsexternalredirectnotallowed/index.html b/files/ja/web/http/cors/errors/corsexternalredirectnotallowed/index.html
new file mode 100644
index 0000000000..db4ce8efe7
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsexternalredirectnotallowed/index.html
@@ -0,0 +1,38 @@
+---
+title: 'Reason: CORS request external redirect not allowed'
+slug: Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed
+tags:
+  - CORS
+  - CORSExternalRedirectNotAllowed
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS request external redirect not allowed</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("CORS")}} リクエストに対して、サーバーが元のリクエストとは異なるオリジンの URL へのリダイレクトを返答しましたが、これは CORS リクエストでは許可されていません。</p>
+
+<p>例えば、 <code>https://service.tld/fetchdata</code> のページがリクエストされ、 HTTP レスポンスが "301 Moved Permanently" 又は "307 Temporary Redirect" 又は "308 Permanent Redirect" で、 <code>Location</code> が <code>https://anotherservice.net/getdata</code> であった場合、この理由で CORS リクエストが失敗します。</p>
+
+<p>問題を修正するには、リダイレクトによって報告された新しい URL を使用するようにコードを更新し、リダイレクトを回避します。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsinvalidallowheader/index.html b/files/ja/web/http/cors/errors/corsinvalidallowheader/index.html
new file mode 100644
index 0000000000..2e8b34980d
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsinvalidallowheader/index.html
@@ -0,0 +1,39 @@
+---
+title: 'Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’'
+slug: Web/HTTP/CORS/Errors/CORSInvalidAllowHeader
+tags:
+  - CORS
+  - CORSInvalidAllowHeader
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSInvalidAllowHeader
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何に失敗したか</h2>
+
+<p>サーバーから送信された {{Glossary("CORS")}} 要求への応答に、一つ以上の無効なヘッダー名を含んだ {{HTTPHeader("Access-Control-Allow-Headers")}} ヘッダーが含まれています。</p>
+
+<p><code>Access-Control-Allow-Headers</code> ヘッダーは、{{Glossary("preflight request", "プリフライト要求")}}への応答の中でサーバーから送信されます。これはどの <a href="/ja/docs/Web/HTTP/Headers">HTTP ヘッダー</a>が CORS 要求で許可されているかをクライアントに知らせます。クライアントの{{Glossary("user agent", "ユーザーエージェント")}}が、このヘッダーで示されたコンマで区切られた値の中から理解できないヘッダーがあれば、このエラーが発生します。</p>
+
+<p>これはほとんどはサーバー側でしか修正できない問題であり、サーバーの構成を変更して、 <code>Access-Control-Allow-Headers</code> ヘッダーから無効又は未知のヘッダー名を送らないようにします。クライアントで使用しているユーザーエージェントの HTTP ライブラリが最新版であるかどうかをチェックするのも良いかもしれません。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="/ja/docs/Web/HTTP/Headers">HTTP ヘッダー</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsinvalidallowmethod/index.html b/files/ja/web/http/cors/errors/corsinvalidallowmethod/index.html
new file mode 100644
index 0000000000..6e40442974
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsinvalidallowmethod/index.html
@@ -0,0 +1,36 @@
+---
+title: 'Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’'
+slug: Web/HTTP/CORS/Errors/CORSInvalidAllowMethod
+tags:
+  - CORS
+  - CORSInvalidAllowMethod
+  - HTTP
+  - HTTPS
+  - console
+  - エラー
+  - オリジン間
+  - メッセージ
+translation_of: Web/HTTP/CORS/Errors/CORSInvalidAllowMethod
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何に失敗したか</h2>
+
+<p>サーバーから送信された {{Glossary("CORS")}} 要求への応答に、一つ以上の無効なメソッド名を含んだ {{HTTPHeader("Access-Control-Allow-Methods")}} ヘッダーが含まれています。</p>
+
+<p><code>Access-Control-Allow-Methods</code> ヘッダーは、どの <a href="/ja/docs/Web/HTTP/Methods">HTTP 要求メソッド</a>が CORS 要求に対応しているかをクライアントに知らせます。ヘッダーの値は、{{HTTPMethod("GET")}}, {{HTTPMethod("POST")}}, {{HTTPMethod("HEAD")}} のような HTTP メソッド名をコンマで区切った文字列です。クライアントの{{Glossary("user agent", "ユーザーエージェント")}}が指定された値を理解できない場合、このエラーが発生します。</p>
+
+<p>これはほとんどはサーバー側でしか修正できない問題であり、サーバーの構成を変更して、 <code>Access-Control-Allow-Methods</code> ヘッダーから無効又は未知のメソッド名を送らないようにします。クライアントで使用しているユーザーエージェントの HTTP ライブラリが最新版であるかどうかをチェックするのも良いかもしれません。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="/ja/docs/Web/HTTP/Headers">HTTP ヘッダー</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsmethodnotfound/index.html b/files/ja/web/http/cors/errors/corsmethodnotfound/index.html
new file mode 100644
index 0000000000..3f391edcd9
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsmethodnotfound/index.html
@@ -0,0 +1,45 @@
+---
+title: 'Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’'
+slug: Web/HTTP/CORS/Errors/CORSMethodNotFound
+tags:
+  - CORS
+  - CORSMethodNotFound
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSMethodNotFound
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("CORS")}} リクエストで使われている HTTP メソッドが、レスポンスの {{HTTPHeader("Access-Control-Allow-Methods")}} ヘッダーで指定されたメソッドの一覧に含まれていません。このヘッダーは、 CORS を使用してリクエストで指定された URL にアクセスする時に使われる HTTP メソッドのコンマ区切りのリストを指定します。リクエストが他のメソッドを使用していると、このエラーが発生します。</p>
+
+<p>例えば、レスポンスに以下の行が含まれていると、</p>
+
+<pre>Access-Control-Allow-Methods: GET,HEAD,POST</pre>
+
+<p>{{HTTPMethod("PUT")}} リクエストを使おうとすると、リクエストが失敗し、このエラーが発生します。</p>
+
+<p>コードからサービスにアクセスするときは、許可された HTTP メソッドのみを使用するように確認してください。</p>
+
+<p><strong>メモ:</strong> サーバーが <code>Access-Control-Allow-methods</code> ヘッダーに理解できない又は未定義のメソッド名を含めた場合、別なエラー <code><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz' in CORS header ‘Access-Control-Allow-Methods’</a></code> が発生します。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="/ja/docs/Web/HTTP/Methods">HTTP リクエストメソッド</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsmissingallowcredentials/index.html b/files/ja/web/http/cors/errors/corsmissingallowcredentials/index.html
new file mode 100644
index 0000000000..6c1de312ae
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsmissingallowcredentials/index.html
@@ -0,0 +1,44 @@
+---
+title: 'Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’'
+slug: Web/HTTP/CORS/Errors/CORSMIssingAllowCredentials
+tags:
+  - CORS
+  - CORSMissingAllowCredentials
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSMIssingAllowCredentials
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("CORS")}} リクエストが認証情報を使用してサーバーの許可を要求されていますが、サーバーの {{HTTPHeader("Access-Control-Allow-Credentials")}} ヘッダーの値が <code>true</code> に設定されておらず、利用できるようになっていません。</p>
+
+<p>この問題をクライアント側で解決するには、コードを修正して認証情報を使用せずにリクエストするようにしてください。</p>
+
+<ul>
+ <li>リクエストが {{domxref("XMLHttpRequest")}} を用いて発行されている場合は、 {{domxref("XMLHttpRequest.withCredentials", "withCredentials")}} に <code>true</code> を設定しないよう確認してください。</li>
+ <li><a href="/ja/docs/Web/API/Server-sent_events">Server-sent event</a> を使用している場合は、 {{domxref("EventSource.withCredentials")}} が <code>false</code> (既定値) であることを確認してください。</li>
+ <li><a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a> を使用している場合は、 {{domxref("Request.credentials")}} が <code>"omit"</code> であることを確認してください。</li>
+</ul>
+
+<p>サーバーの構成を変更してこのエラーを除去するには、サーバーの構成で <code>Access-Control-Allow-Credentials</code> ヘッダーの値に <code>true</code> を設定するよう調整してください。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html b/files/ja/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html
new file mode 100644
index 0000000000..42e8f25f2f
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsmissingallowheaderfrompreflight/index.html
@@ -0,0 +1,39 @@
+---
+title: >-
+  Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from
+  CORS preflight channel
+slug: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight
+tags:
+  - CORS
+  - CORSMissingAllowHeaderFromPreflight
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何に失敗したのか</h2>
+
+<p> <code>Access-Control-Allow-Headers</code> ヘッダーがサーバーから送信され、どのヘッダーが {{Glossary("CORS")}} 要求に対応しているかを知らせます。 <code>Access-Control-Allow-Headers</code> の値はコンマ区切りのヘッダー名のリストで、 "<code>X-Custom-Information</code>" やその他の標準的かつ基本的ではないヘッダー名 (常に許可されているもの) を記述します。</p>
+
+<p>このエラーは明確に許可されていないヘッダー (すなわち、サーバーから送られる <code>Access-Control-Allow-Headers</code> ヘッダーで指定されたリストに含まれていないもの) のプリフライトリクエストを行おうとしたときに発生します。これを修正するには、サーバーが指定されたヘッダーを許可するように更新するか、このヘッダーを使用しないようにする必要があります。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="/ja/docs/Web/HTTP/Headers">HTTP ヘッダー</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsmissingalloworigin/index.html b/files/ja/web/http/cors/errors/corsmissingalloworigin/index.html
new file mode 100644
index 0000000000..80e851c0dd
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsmissingalloworigin/index.html
@@ -0,0 +1,58 @@
+---
+title: 'Reason: CORS header ''Access-Control-Allow-Origin'' missing'
+slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin
+tags:
+  - CORS
+  - CORSMissingAllowOrigin
+  - Cross-Origin
+  - Error
+  - HTTP
+  - HTTPS
+  - Messages
+  - Reasons
+  - Security
+  - console
+  - troubleshooting
+translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox notranslate">Reason: CORS header 'Access-Control-Allow-Origin' missing</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("CORS")}} リクエストへのレスポンスが、リソースが現在のオリジン内で操作しているコンテンツによってアクセスできるかどうかを判断するために使われる、必須の {{HTTPHeader("Access-Control-Allow-Origin")}} ヘッダーを欠いています。</p>
+
+<p>サーバーを自分で制御できる場合は、要求しているサイトのオリジンを <code>Access-Control-Allow-Origin</code> ヘッダーの値に追加して、アクセスが許可されているドメインの一覧に追加してください。</p>
+
+<p>例えば、 https://amazing.site のサイトが CORS を使用したリソースにアクセスできるよう許可するためには、ヘッダーを以下のようにしてください。</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: https://amazing.site</pre>
+
+<p><code>*</code> を使用することで、あらゆるサイトにアクセスを許可するようサイトを構成することもできます。これは公開 API にのみ使用してください。非公開の API には <code>*</code> を使用するべきではなく、代わりに具体的なドメインやドメインの一覧を設定してください。加えて、ワイルドカードは {{htmlattrxref("crossorigin")}} 属性が <code>anonymous</code> に設定された要求にのみ動作し、リクエストでは Cookie のような資格情報の送信を抑制します。</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: *</pre>
+
+<div class="warning">
+<p><strong>警告:</strong> ワイルドカードを使用して、非公開の API へのアクセスをすべてのサイトに許可することは、悪い考えです。</p>
+</div>
+
+<p>何らかのサイトが CORS リクエストを <code>*</code> ワイルドカードを使用すること<em>なく</em> (たとえば資格情報を有効にする場合) 利用できるようにするには、サーバーにリクエストの <code>Origin</code> ヘッダーの値を読み取り、その値を <code>Access-Control-Allow-Origin</code> に設定することに加えて、一部のヘッダーがオリジンに応じて動的に設定されることを示すために <code>Vary: Origin</code> ヘッダーを設定する必要があります。</p>
+
+<p>例えば Apache では、サーバー構成 (の中の <code>&lt;Directory&gt;</code>, <code>&lt;Location&gt;</code>, <code>&lt;Files&gt;</code>, <code>&lt;VirtualHost&gt;</code> のうち適切な節) に次のような行を追加してください。構成はふつう、 <code>.conf</code> ファイル又は (一般的な名前は <code>httpd.conf</code> や <code>apache.conf</code>) 又は <code>.htaccess</code> ファイルにあります。</p>
+
+<pre class="notranslate">Header set Access-Control-Allow-Origin '<em>origin-list</em>'</pre>
+
+<p>Nginx では、このヘッダーを設定するコマンドは次の通りです。</p>
+
+<pre class="notranslate">add_header 'Access-Control-Allow-Origin' '<em>origin-list</em>'</pre>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsmultiplealloworiginnotallowed/index.html b/files/ja/web/http/cors/errors/corsmultiplealloworiginnotallowed/index.html
new file mode 100644
index 0000000000..70d3c0e7fb
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsmultiplealloworiginnotallowed/index.html
@@ -0,0 +1,37 @@
+---
+title: 'Reason: Multiple CORS header ''Access-Control-Allow-Origin'' not allowed'
+slug: Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed
+tags:
+  - CORS
+  - CORSMultipleAllowOriginNotAllowed
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>複数の {{HTTPHeader("Access-Control-Allow-Origin")}} ヘッダーがサーバから送信されました。これは許可されていません。</p>
+
+<p>サーバーへのアクセス権があるのであれば、実装を変更して <code>Access-Control-Allow-Origin</code> ヘッダーで{{Glossary("origin", "オリジン")}}を返すようにしてください。ブラウザーは単一のオリジンか null のどちらかの値しか受け付けないので、オリジンのリストを送り返すことはできません。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsnotsupportingcredentials/index.html b/files/ja/web/http/cors/errors/corsnotsupportingcredentials/index.html
new file mode 100644
index 0000000000..efa77d5a10
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsnotsupportingcredentials/index.html
@@ -0,0 +1,46 @@
+---
+title: >-
+  Reason: Credential is not supported if the CORS header
+  ‘Access-Control-Allow-Origin’ is ‘*’
+slug: Web/HTTP/CORS/Errors/CORSNotSupportingCredentials
+tags:
+  - CORS
+  - CORSNotSupportingCredentials
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSNotSupportingCredentials
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("CORS")}} リクエストが認証フラグ付きで試みられましたが、サーバーが {{HTTPHeader("Access-Control-Allow-Origin")}} の値としてワイルドカード (<code>"*"</code>) を使用して構成されており、認証情報を利用することが許可されていません。</p>
+
+<p>この問題をクライアント側で修正するには、 CORS リクエストを発行する際に認証フラグの値を確実に <code>false</code> にするだけです。</p>
+
+<ul>
+ <li>リクエストが {{domxref("XMLHttpRequest")}} を用いて発行されている場合は、 {{domxref("XMLHttpRequest.withCredentials", "withCredentials")}} に <code>true</code> を設定しないよう確認してください。</li>
+ <li><a href="/ja/docs/Web/API/Server-sent_events">Server-sent event</a> を使用している場合は、 {{domxref("EventSource.withCredentials")}} が <code>false</code> (既定値) であることを確認してください。</li>
+ <li><a href="/ja/docs/Web/API/Fetch_API">Fetch API</a> を使用している場合は、 {{domxref("Request.credentials")}} が <code>"omit"</code> であることを確認してください。</li>
+</ul>
+
+<p>サーバーの動作を調整する必要がある場合は、 <code>Access-Control-Allow-Origin</code> の画像を変更して、クライアントが読み込まれたオリジンへのアクセスを許可する必要があるでしょう。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsoriginheadernotadded/index.html b/files/ja/web/http/cors/errors/corsoriginheadernotadded/index.html
new file mode 100644
index 0000000000..adf59fff6b
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsoriginheadernotadded/index.html
@@ -0,0 +1,36 @@
+---
+title: 'Reason: CORS header ‘Origin’ cannot be added'
+slug: Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded
+tags:
+  - CORS
+  - CORSOriginHeaderNotAdded
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS header ‘Origin’ cannot be added</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("user agent", "ユーザーエージェント")}}が必要な {{HTTPHeader("Origin")}} を {{Glossary("HTTP")}} リクエストに追加することができませんでした。すべての CORS リクエストは <code>Origin</code> ヘッダーを含んでいなければなりません。</p>
+
+<p>これは例えば、 JavaScript のコードが複数のドメインのコンテンツにアクセスできるよう高い権限で実行されている場合などに起こることがあります。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corspreflightdidnotsucceed/index.html b/files/ja/web/http/cors/errors/corspreflightdidnotsucceed/index.html
new file mode 100644
index 0000000000..830e1e9ae3
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corspreflightdidnotsucceed/index.html
@@ -0,0 +1,39 @@
+---
+title: 'Reason: CORS preflight channel did not succeed'
+slug: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed
+tags:
+  - CORS
+  - CORSPreflightDidNotSucceed
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - トラブルシューティング
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS preflight channel did not succeed</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何に失敗したか</h2>
+
+<p>{{Glossary("CORS")}} の要求がプリフライトを必要としていますが、プリフライトが実行できませんでした。プロフライトが失敗したと理由として考えられることは複数あります。</p>
+
+<ul>
+ <li>すでにサイト間の要求でプリフライトが行われており、プリフライトを再び行うことが許可されていない。コードを確認して、一つのコネクションで一度だけプリフライトを行うようにしてください。</li>
+ <li>プリフライト要求は単に通常のネットワークエラーの類で失敗した。</li>
+</ul>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/corsrequestnothttp/index.html b/files/ja/web/http/cors/errors/corsrequestnothttp/index.html
new file mode 100644
index 0000000000..33105d9d22
--- /dev/null
+++ b/files/ja/web/http/cors/errors/corsrequestnothttp/index.html
@@ -0,0 +1,42 @@
+---
+title: 'Reason: CORS request not HTTP'
+slug: Web/HTTP/CORS/Errors/CORSRequestNotHttp
+tags:
+  - CORS
+  - CORSRequestNotHttp
+  - HTTP
+  - HTTPS
+  - エラー
+  - オリジン間
+  - コンソール
+  - セキュリティ
+  - メッセージ
+  - 理由
+translation_of: Web/HTTP/CORS/Errors/CORSRequestNotHttp
+---
+<div>{{HTTPSidebar}}</div>
+
+<h2 id="Reason" name="Reason">理由</h2>
+
+<pre class="syntaxbox">Reason: CORS request not HTTP</pre>
+
+<h2 id="What_went_wrong" name="What_went_wrong">何が悪いのか</h2>
+
+<p>{{Glossary("CORS")}} リクエストは URL スキームが HTTPS の場合のみ利用できますが、リクエストで指定された URL が異なる種類のものです。これは、ローカルファイルを指定する URL が、 <code>file:///</code> の URL を使用している場合によく起こります。</p>
+
+<p>この問題を修正するには、単純に CORS に関するリクエストを発行する際に HTTPS の URL を使用するようにしてください。</p>
+
+<h3 id="Firefox_68におけるローカルファイルセキュリティ">Firefox 68におけるローカルファイルセキュリティ</h3>
+
+<p>Firefox 67以前ではユーザが <code>file:///</code> URIを用いてページを開いたとき、ページのオリジンはその開かれたページのあるディレクトリとして定義されていました。同じディレクトリやそのサブディレクトリにあるリソースは、CORS同一オリジンルールを適用する際には同一オリジンとみなされていました。</p>
+
+<p>Firefox 68以降では <a href="https://www.mozilla.org/en-US/security/advisories/mfsa2019-21/#CVE-2019-11730">CVE-2019-11730 </a>の対策として、 <code>file:///</code> URIを用いて開かれたページのオリジンは、それだけのものとして定義されます。つまり、同じディレクトリやそのサブディレクトリにあるリソースは、CORS同一オリジンルールを満たさなくなりました。この新たな振る舞いは、<code>privacy.file_unique_origin</code> 設定を用いてデフォルトで有効になっています。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="/ja/docs/Learn/Common_questions/What_is_a_URL">URL とは</a></li>
+</ul>
diff --git a/files/ja/web/http/cors/errors/index.html b/files/ja/web/http/cors/errors/index.html
new file mode 100644
index 0000000000..c7b4ce9fc3
--- /dev/null
+++ b/files/ja/web/http/cors/errors/index.html
@@ -0,0 +1,74 @@
+---
+title: CORS のエラー
+slug: Web/HTTP/CORS/Errors
+tags:
+  - CORS
+  - HTTP
+  - HTTPS
+  - エラー
+  - コンソール
+  - セキュリティ
+  - トラブル解決
+  - メッセージ
+  - 同一オリジン
+translation_of: Web/HTTP/CORS/Errors
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary"><ruby><a href="/ja/docs/Web/HTTP/CORS">オリジン間リソース共有</a><rp> (</rp><rt>Cross-Origin Resource Sharing</rt><rp>) </rp></ruby> ({{Glossary("CORS")}}) は、サーバーが<a href="/ja/docs/Web/Security/Same-origin_policy">同一オリジンポリシー</a>を緩和することができる標準です。</span>例えば、サイトが埋め込み可能なサービスを提供する場合、このような制約を緩和する必要があるかもしれません。このような CORS の構成の設定は必ずしも簡単ではなく、いくらか冒険的です。これらのページでは、よくある CORS のエラーメッセージと解決方法を調査します。</p>
+
+<p>CORS 構成が正しく設定されていないと、ブラウザーコンソールには <code>"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"</code> のようなエラーを表示して、リクエストが CORS のセキュリティ規則を侵害しているためにブロックされたことを示します。これは必ずしも設定ミスとは限りません。実際には、ユーザーのウェブアプリケーションおよびリモートの外部サービスからのリクエストが、意図的に許可されていない場合もあります。しかし、ただし、エンドポイントが使用可能である場合、成功するためにはデバッグが必要です。</p>
+
+<h2 id="Identifying_the_issue" name="Identifying_the_issue">問題の識別</h2>
+
+<p>CORS の構成に関する問題を理解するために、どのリクエストが、なぜ失敗したのかを調べる必要があります。そのためには以下の手順が役立つかもしれません。</p>
+
+<ol>
+ <li>問題のウェブサイトやウェブアプリを実行し、<a href="/ja/docs/Tools">開発者ツール</a>を開く。</li>
+ <li>失敗するトランザクションを再現してみて、<a href="/ja/docs/Tools/Web_Console">コンソール</a>で CORS 違反エラーメッセージが表示されるかを調べる。おそらく次のように見える。</li>
+</ol>
+
+<p><img alt="CORS エラーを表示している Firefox コンソール" src="https://mdn.mozillademos.org/files/16050/cors-error2.png"></p>
+
+<p>エラーメッセージのテキストは以下のようなものになるでしょう。</p>
+
+<pre>Cross-Origin Request Blocked: The Same Origin Policy disallows
+reading the remote resource at <em>https://some-url-here</em>. (<em>Reason:
+additional information here</em>).</pre>
+
+<div class="note">
+<p><strong>メモ:</strong> セキュリティ上の理由から、 CORS リクエストで何を失敗したかについては <em>JavaScript コードからは特定できません</em>。コードから分かることは、エラーが発生したことだけです。何を失敗したかを特定するための唯一の方法は、詳細をブラウザーのコンソールで見ることです。</p>
+</div>
+
+<h2 id="CORS_error_messages" name="CORS_error_messages">CORS のエラーメッセージ</h2>
+
+<p>Firefox のコンソールは、 CORS のためにリクエストが失敗した場合はコンソールにメッセージを表示します。エラーテキストには、何が失敗したのかの分析が追加された「reason」の部分があります。 reason のメッセージは以下の通りです。メッセージをクリックすると、エラーをより詳細に説明し、可能な解決方法を提供する記事を開くことができます。</p>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSDisabled">Reason: CORS disabled</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed">Reason: CORS request did not succeed</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded">Reason: CORS header ‘Origin’ cannot be added</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed">Reason: CORS request external redirect not allowed</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp">Reason: CORS request not http</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ missing</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed">Reason: CORS preflight channel did not succeed</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</a></li>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</a></li>
+</ul>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>用語集: {{Glossary("CORS")}}</li>
+ <li><a href="/ja/docs/Web/HTTP/CORS">CORS 入門</a></li>
+ <li><a href="/ja/docs/Web/HTTP/Server-Side_Access_Control">サーバー側 CORS 設定</a></li>
+ <li><a href="/ja/docs/Web/HTML/CORS_enabled_image">CORS 有効化の画像</a></li>
+ <li><a href="/ja/docs/Web/HTML/CORS_settings_attributes">CORS の設定属性</a></li>
+ <li><a href="https://www.test-cors.org">https://www.test-cors.org</a> – CORS リクエストの試験ページ</li>
+</ul>
diff --git a/files/ja/web/http/cors/index.html b/files/ja/web/http/cors/index.html
new file mode 100644
index 0000000000..672d9acf0c
--- /dev/null
+++ b/files/ja/web/http/cors/index.html
@@ -0,0 +1,509 @@
+---
+title: オリジン間リソース共有 (CORS)
+slug: Web/HTTP/CORS
+tags:
+  - AJAX
+  - CORS
+  - Fetch
+  - Fetch API
+  - HTTP
+  - HTTP アクセス制御
+  - Security
+  - XMLHttpRequest
+  - 'l10n:priority'
+  - オリジン間リソース共有
+  - セキュリティ
+  - 同一オリジンポリシー
+translation_of: Web/HTTP/CORS
+---
+<div>{{HTTPSidebar}}</div>
+
+<p><span class="seoSummary"><ruby><strong>オリジン間リソース共有</strong><rp> (</rp><rt>Cross-Origin Resource Sharing</rt><rp>) </rp></ruby> ({{Glossary("CORS")}}) は、追加の {{Glossary("HTTP")}} ヘッダーを使用して、ある{{glossary("origin", "オリジン")}}で動作しているウェブアプリケーションに、異なるオリジンにある選択されたリソースへのアクセス権を与えるようブラウザーに指示するための仕組みです。</span>ウェブアプリケーションは、自分とは異なるオリジン (ドメイン、プロトコル、ポート番号) にあるリソースをリクエストするとき、オリジン間 HTTP リクエストを実行します。</p>
+
+<p>オリジン間リクエストの一例: <code>https://domain-a.com</code> で提供されているウェブアプリケーションのフロントエンド JavaScript コードが {{domxref("XMLHttpRequest")}} を使用して <code>https://domain-b.com/data.json</code> へリクエストを行う場合。</p>
+
+<p>セキュリティ上の理由から、ブラウザーは、スクリプトによって開始されるオリジン間 HTTP リクエストを制限しています。例えば、 <code>XMLHttpRequest</code>や <a href="/ja/docs/Web/API/Fetch_API">Fetch API</a> は<ruby><a href="/ja/docs/Web/Security/Same-origin_policy">同一オリジンポリシー</a><rp> (</rp><rt>same-origin policy</rt><rp>) </rp></ruby>に従います。つまり、これらの API を使用するウェブアプリケーションは、そのアプリケーションが読み込まれたのと同じオリジンに対してのみリソースのリクエストを行うことができ、それ以外のオリジンの場合は正しい CORS ヘッダーを含んでいることが必要です。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/14295/CORS_principle.png" style="height: 643px; width: 925px;"></p>
+
+<p>CORS の仕組みは、安全なオリジン間のリクエストとブラウザー・サーバー間のデータ転送を支援します。最近のブラウザーは CORS を <code>XMLHttpRequest</code> や <a href="/ja/docs/Web/API/Fetch_API">Fetch</a> などの API で使用して、オリジン間 HTTP リクエストのリスクの緩和に役立てています。</p>
+
+<h2 id="Who_should_read_this_article" name="Who_should_read_this_article">この記事を読むべき人</h2>
+
+<p>誰もが読むべきです。</p>
+
+<p>もっと具体的に言えば、この記事は<strong>ウェブ管理者</strong>、<strong>サーバー開発者</strong>、<strong>フロントエンド開発者</strong>向けです。最近のブラウザーはヘッダーやポリシーの強制を含む、オリジン間共有のクライアント側コンポーネントを扱います。しかし CORS 標準は、サーバーが新たなリクエストヘッダーやレスポンスヘッダーを扱わなければならないことを示しています。サーバー開発者向けには、<a href="/ja/docs/Web/HTTP/Server-Side_Access_Control">サーバーの観点によるオリジン間共有 (PHP コードスニペット付き)</a> についての議論を合わせてお読みください。</p>
+
+<h2 id="What_requests_use_CORS" name="What_requests_use_CORS">CORS を使用したリクエストとは</h2>
+
+<p>この<a class="external" href="https://fetch.spec.whatwg.org/#http-cors-protocol">オリジン間共有仕様</a>は、以下のようなサイト間 HTTP リクエストを有効にすることができます。</p>
+
+<ul>
+ <li>前述のように {{domxref("XMLHttpRequest")}} または <a href="/ja/docs/Web/API/Fetch_API">Fetch API</a> を呼び出す。</li>
+ <li>ウェブフォント (CSS の <code>@font-face</code> で別ドメインのフォントを利用するため)。<a class="external" href="https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements">これによりサーバーは、許可したウェブサイトのみから読み込みや利用ができる TrueType フォントを提供できます</a>。</li>
+ <li><a href="/ja/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL">WebGL テクスチャ</a>。</li>
+ <li>{{domxref("CanvasRenderingContext2D.drawImage()", "drawImage()")}} を使用してキャンバスに描画される画像やビデオフレーム。</li>
+ <li><a href="/ja/docs/Web/CSS/CSS_Shapes/Shapes_From_Images">画像から生成する CSS シェイプ</a>。</li>
+</ul>
+
+<p>この記事では、オリジン間リソース共有の全般的な説明と併せて、 HTTP ヘッダーの要件についても説明します。</p>
+
+<h2 id="Functional_overview" name="Functional_overview">機能概要</h2>
+
+<p>オリジン間リソース共有の仕様は、ウェブブラウザーから情報を読み取ることを許可されているオリジンをサーバーが記述することができる、新たな <a href="/ja/docs/Web/HTTP/Headers">HTTP ヘッダー</a>を追加することで作用します。加えて仕様書では、サーバーの情報に副作用を引き起こすことがある HTTP のリクエストメソッド (特に {{HTTPMethod("GET")}} 以外の HTTP メソッドや、特定の <a href="/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME タイプ</a>を伴う {{HTTPMethod("POST")}}) のために、ブラウザーが HTTP の {{HTTPMethod("OPTIONS")}} リクエストメソッドを用いて、あらかじめリクエストの「プリフライト」 (サーバーから対応するメソッドの一覧を収集すること) を行い、サーバーの「認可」のもとに実際のリクエストを送信することを指示しています。サーバーはリクエスト時に「資格情報」 (<a href="/ja/docs/Web/HTTP/Cookies">Cookie</a> や <a href="/en-US/docs/Web/HTTP/Authentication">HTTP 認証</a> など) を送信するべきかをクライアントに伝えることもできます。</p>
+
+<p>CORS は様々なエラーで失敗することがありますが、セキュリティ上の理由から、エラーについて <em>JavaScript から知ることができない</em>よう定められています。コードからはエラーが発生したということしか分かりません。何が悪かったのかを具体的に知ることができる唯一の方法は、ブラウザーのコンソールで詳細を見ることです。</p>
+
+<p>以降の節ではシナリオの説明に加え、 HTTP ヘッダーの使い方の詳細も提供します。</p>
+
+<h2 id="Examples_of_access_control_scenarios" name="Examples_of_access_control_scenarios">アクセス制御シナリオの例</h2>
+
+<p>オリジン間リソース共有がどのように動作するかを説明する3つのシナリオを示します。これらの例はすべて {{domxref("XMLHttpRequest")}} を用いており、対応しているブラウザーにおいて、サイトをまたいでアクセスすることができます。</p>
+
+<p>サーバー側から見たオリジン間リソース共有の説明 (PHP のコードスニペットを含む) は <a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-Side Access Control (CORS)</a> の記事にあります。</p>
+
+<h3 id="Simple_requests" name="Simple_requests">単純リクエスト</h3>
+
+<p>リクエストによっては <a href="#Preflighted_requests">CORS プリフライト</a>を引き起こさないものがあります。これをこの記事では<em>「単純リクエスト」</em>と呼んでいますが、 (CORS を定義している) {{SpecName('Fetch')}} 仕様書ではこの用語を使用していません。 「単純リクエスト」は、<strong>以下のすべての条件を満たす</strong>ものです。</p>
+
+<ul>
+ <li>許可されているメソッドのうちの一つであること。
+  <ul>
+   <li>{{HTTPMethod("GET")}}</li>
+   <li>{{HTTPMethod("HEAD")}}</li>
+   <li>{{HTTPMethod("POST")}}</li>
+  </ul>
+ </li>
+ <li>ユーザーエージェントによって自動的に設定されたヘッダー (たとえば {{HTTPHeader("Connection")}}、 {{HTTPHeader("User-Agent")}}、 または <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">Fetch 仕様書で「禁止ヘッダー名」として定義されているヘッダー</a>) を除いて、手動で設定できるヘッダーは、 <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">Fetch 仕様書で「CORS セーフリストリクエストヘッダー」として定義されている</a>以下のヘッダーだけです。
+  <ul>
+   <li>{{HTTPHeader("Accept")}}</li>
+   <li>{{HTTPHeader("Accept-Language")}}</li>
+   <li>{{HTTPHeader("Content-Language")}}</li>
+   <li>{{HTTPHeader("Content-Type")}} (但し、下記の要件を満たすもの)</li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li>
+   <li>{{HTTPHeader("Downlink")}}</li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li>
+   <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li>
+  </ul>
+ </li>
+ <li>{{HTTPHeader("Content-Type")}} ヘッダーでは以下の値のみが許可されています。
+  <ul>
+   <li><code>application/x-www-form-urlencoded</code></li>
+   <li><code>multipart/form-data</code></li>
+   <li><code>text/plain</code></li>
+  </ul>
+ </li>
+ <li>リクエストに使用されるどの {{domxref("XMLHttpRequestUpload")}} にもイベントリスナーが登録されていないこと。これらは正しく {{domxref("XMLHttpRequest.upload")}} を使用してアクセスされます。</li>
+ <li>リクエストに {{domxref("ReadableStream")}} オブジェクトが使用されていないこと。</li>
+</ul>
+
+<div class="note"><strong>注:</strong> これらはウェブコンテンツが発行可能になっているサイト間リクエストと同じ種類のものであり、サーバーが適切なヘッダーを送信しなければレスポンスデータは送信元へ送られません。従ってクロスサイトリクエストフォージェリ対策をしているサイトは、 HTTP アクセス制限について新たに心配することはありません。</div>
+
+<div class="note">
+<p><strong>注:</strong> WebKit Nightly および Safari Technology Preview は、 {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, {{HTTPHeader("Content-Language")}} ヘッダーの値に追加の制限を掛けています。これらのヘッダーが「標準外」の値の場合、 WebKit/Safari はそのリクエストが「単純リクエスト」の条件に合うとは判断しません。 WebKit/Safari がこれらのヘッダーのどの値を「標準外」と判断するかについては、以下の WebKit のバグを除いて文書化されていません。</p>
+
+<ul>
+ <li><a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a></li>
+ <li><a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a></li>
+ <li><a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a></li>
+</ul>
+
+<p>これは仕様の一部ではないので、他のブラウザーはこの追加の制限を実装していません。</p>
+</div>
+
+<p>例えば、ドメイン <code class="plain">https://foo.example</code> にあるウェブコンテンツがドメイン <code class="plain">https://bar.other</code> にあるコンテンツを呼び出したいと仮定します。以下のようなコードが <code>foo.example</code> 内の JavaScript で使用されるかもしれません。</p>
+
+<pre class="brush: js notranslate" id="line1">const xhr = new XMLHttpRequest();
+const url = 'https://bar.other/resources/public-data/';
+
+xhr.open('GET', url);
+xhr.onreadystatechange = someHandler;
+xhr.send();
+</pre>
+
+<p>これは、特権を扱うために CORS ヘッダーを使用して、クライアントとサーバーの間で簡単なデータ交換を行います。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/17214/simple-req-updated.png" style="height: 490px; width: 1023px;"></p>
+
+<p>この場合、ブラウザーがサーバーに何を送信し、サーバーが何を返すかを見てみましょう。</p>
+
+<pre class="brush: shell notranslate">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
+<strong>Origin: https://foo.example</strong>
+</pre>
+
+<p>特筆すべきリクエストヘッダーは {{HTTPHeader("Origin")}} であり、呼び出しが <code class="plain">https://foo.example</code> から来たことを表します。</p>
+
+<pre class="notranslate">HTTP/1.1 200 OK
+Date: Mon, 01 Dec 2008 00:23:53 GMT
+Server: Apache/2
+<strong>Access-Control-Allow-Origin: *</strong>
+Keep-Alive: timeout=2, max=100
+Connection: Keep-Alive
+Transfer-Encoding: chunked
+Content-Type: application/xml
+
+[…XML データ…]</pre>
+
+<p>レスポンスでは、サーバーが {{HTTPHeader("Access-Control-Allow-Origin")}} ヘッダーを返信しています。 {{HTTPHeader("Origin")}} ヘッダーと {{HTTPHeader("Access-Control-Allow-Origin")}} ヘッダーの使用は、最も単純なアクセス制御プロトコルを表しています。この場合、サーバーは <code>Access-Control-Allow-Origin: *</code> を返しており、これはそのリソースが<strong>すべての</strong>ドメインからアクセスできることを意味します。 <code class="plain">https://bar.other</code> にあるリソースの所有者が、リソースへの制限を <code class="plain">https://foo.example</code> からのリクエスト<em>のみ</em>に制限したいと考えていた場合は、以下のように送信します。</p>
+
+<pre class="notranslate"><code class="plain">Access-Control-Allow-Origin: https://foo.example</code></pre>
+
+<p><code class="plain">https://foo.example</code> 以外のドメインはすべて、サイト間の方法でリソースにアクセスすることがサイト間の方法でリソースにアクセスすることができなくなりました。リソースへのアクセスを許可するには、 <code>Access-Control-Allow-Origin</code> ヘッダーに、リクエストの <code>Origin</code> ヘッダーの中で送信された値を含めてください。</p>
+
+<h3 id="Preflighted_requests" name="Preflighted_requests">プリフライトリクエスト</h3>
+
+<p><a href="#Simple_requests">「単純リクエスト」 (前述)</a> とは異なり、「プリフライト」リクエストは始めに {{HTTPMethod("OPTIONS")}} メソッドによる HTTP リクエストを他のドメインにあるリソースに向けて送り、実際のリクエストを送信しても安全かどうかを確かめます。サイト間リクエストがユーザーデータに影響を与える可能性があるような場合に、このようにプリフライトを行います。</p>
+
+<p>以下は、プリフライトが行われるリクエストの例です。</p>
+
+<pre class="brush: js notranslate" id="line1">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('&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;');
+</pre>
+
+<p>上記の例では、 <code>POST</code> で送信する XML の本体を作成しています。また、標準外の <code>X-PINGOTHER</code> HTTP リクエストヘッダーを設定しています。このようなヘッダーは HTTP/1.1 プロトコルに含まれていませんが、ウェブアプリケーションでは一般的に便利なものです。リクエストで <code>Content-Type</code> に <code>application/xml</code> を使用しており、かつカスタムヘッダーを設定しているため、このリクエストではプリフライトを行います。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/17268/preflight_correct.png" style="height: 1076px; width: 1024px;"></p>
+
+<div class="blockIndicator note">
+<p><strong>注</strong>: 後述するように、実際の <code>POST</code> リクエストには <code>Access-Control-Request-*</code> ヘッダーが含まれず、 <code>OPTIONS</code> リクエストのみで必要になります。</p>
+</div>
+
+<p>クライアントとサーバーとの間のやりとりの全容を見てみましょう。最初のやり取りは<em>プリフライトリクエスト/レスポンス</em>です。</p>
+
+<pre class="brush: shell notranslate">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: http://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
+</pre>
+
+<p>プリフライトリクエストが完了したら、実際のリクエストを送ります。</p>
+
+<pre class="brush: shell notranslate">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
+
+&lt;person&gt;&lt;name&gt;Arun&lt;/name&gt;&lt;/person&gt;
+
+
+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]
+</pre>
+
+<p>上記の1-10行目は {{HTTPMethod("OPTIONS")}} メソッドによるプリフライトを表します。ブラウザーは上記で使用された JavaScript コードで使用しているリクエストの引数に基づいて、プリフライトの送信が必要であることを判断します。これによりサーバーは実際のリクエストの引数によって送られるリクエストを受け入れ可能かをレスポンスできます。 OPTIONS はサーバーから付加的な情報を得るために用いる HTTP/1.1 のメソッドであり、また{{Glossary("safe","安全")}}なメソッド、つまりリソースを変更するためには使用できないメソッドです。 OPTIONS リクエストと合わせて、他にリクエストヘッダーを2つ送信していることに注意してください (それぞれ9行目と10行目です)。</p>
+
+<pre class="brush: none notranslate">Access-Control-Request-Method: POST
+Access-Control-Request-Headers: X-PINGOTHER, Content-Type
+</pre>
+
+<p>{{HTTPHeader("Access-Control-Request-Method")}} ヘッダーは、プリフライトリクエストの一部として、実際のリクエストが <code>POST</code> リクエストメソッドで送られることをサーバーに通知します。 {{HTTPHeader("Access-Control-Request-Headers")}} ヘッダーは、実際のリクエストにカスタムヘッダーである <code>X-PINGOTHER</code> および Content-Type が含まれることをサーバーに通知します。ここでサーバーは、この状況下でリクエストの受け入れを望むかを判断する機会があります。</p>
+
+<p>上記の13-22行目はサーバーが返すレスポンスであり、リクエストメソッド (<code>POST</code>) とリクエストヘッダー (<code>X-PINGOTHER</code>) を受け入れられることを示しています。特に、16-19行目を見てみましょう。</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Origin: http://foo.example
+Access-Control-Allow-Methods: POST, GET, OPTIONS
+Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
+Access-Control-Max-Age: 86400</pre>
+
+<p>サーバーは <code>Access-Control-Allow-Methods</code> を返しており、これは当該リソースへの問い合わせで <code>POST</code> および <code>GET</code> が実行可能なメソッドであることを伝えます。なお、このヘッダーはレスポンスヘッダーの {{HTTPHeader("Allow")}} と似ていますが、アクセス制御でのみ使用されることに注意してください。</p>
+
+<p>またサーバーは、 <code>Access-Control-Allow-Headers</code> を <code>X-PINGOTHER</code> の値で送信し、これが実際のリクエストで使用されるヘッダーであることを承認しています。 <code>Access-Control-Allow-Methods</code> と同様に、 <code>Access-Control-Allow-Headers</code> は受け入れ可能なヘッダーをカンマ区切りのリストで表します。</p>
+
+<p>最後に <code>Access-Control-Max-Age</code> は、プリフライトリクエストを再び送らなくてもいいように、プリフライトのレスポンスをキャッシュしてよい時間を秒数で与えます。この例では86400秒、つまり24時間です。なお、ブラウザーは個々に<a href="/ja/docs/Web/HTTP/Headers/Access-Control-Max-Age">内部の上限値</a>を持っており、 <code>Access-Control-Max-Age</code> が上回った場合に制限を掛けます。</p>
+
+<h4 id="Preflighted_requests_and_redirects" name="Preflighted_requests_and_redirects">プリフライトリクエストとリダイレクト</h4>
+
+<p>多くのブラウザーは現在、下記のようなプリフライトリクエストのリダイレクトに対応していません。プリフライトリクエストにリダイレクトが発生すると、多くのブラウザーは以下のようなエラーメッセージを報告します。</p>
+
+<blockquote>
+<p>リクエストがプリフライトを必要とするオリジン間リクエストで許可されていない 'https://example.com/foo' にリダイレクトされました。</p>
+</blockquote>
+
+<blockquote>
+<p>リクエストにはプリフライトが必要で、オリジン間のリダイレクトは許可されていません</p>
+</blockquote>
+
+<p>もともと CORS プロトコルはそのような振る舞いを要求していましたが、<a href="https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2">その後で必要がないと変更されました</a>。しかし、多くのブラウザーはまだ変更を実装しておらず、もともと要求されていた振る舞いに従っています。</p>
+
+<p>ブラウザーが仕様に追いつくまで、以下の一方もしくは両方を行うことでこの制限を回避することができます。</p>
+
+<ul>
+ <li>サーバー側の振る舞いを変更して、プリフライトが発生しないようにするか、リダイレクトが発生しないようにする</li>
+ <li>リクエストをプリフライトを起こさない<a href="#Simple_requests">単純リクエスト</a>などに変更する</li>
+</ul>
+
+<p>これらの変更ができない場合は、次のような別な方法があります。</p>
+
+<ol>
+ <li><a href="#Simple_requests">単純リクエスト</a>を行い (Fetch API の {{domxref("Response.url")}} または {{domxref("XMLHttpRequest.responseURL")}} を使用して)、実際のプリフライトリクエストが転送される先を特定する。</li>
+ <li>最初のステップの <code>Response.url</code> または <code>XMLHttpRequest.responseURL</code> で得た URL を使用して、もう一つのリクエスト (「本当の」リクエスト) を行う。</li>
+</ol>
+
+<p>ただし、リクエストに <code>Authorization</code> ヘッダーが存在するためにプリフライトを引き起こすリクエストの場合、上記の手順を使用して制限を回避することはできません。リクエストが行われているサーバーを制御できない限り、まったく回避することはできません。</p>
+
+<h3 id="Requests_with_credentials" name="Requests_with_credentials">資格情報を含むリクエスト</h3>
+
+<p>{{domxref("XMLHttpRequest")}} や <a href="/ja/docs/Web/API/Fetch_API">Fetch</a> と CORS の両方によって明らかになる最も興味深い機能は、 <a href="/ja/docs/Web/HTTP/Cookies">HTTP クッキー</a>と HTTP 資格情報によってわかる「資格情報を含む」リクエストを作成することができることです。既定では、サイト間の <code>XMLHttpRequest</code> または <a href="/ja/docs/Web/API/Fetch_API">Fetch</a> の呼び出しにおいて、ブラウザーは資格情報を送信<strong>しません</strong>。 <code>XMLHttpRequest</code> オブジェクトまたは {{domxref("Request")}} のコンストラクターの呼び出し時に、特定のフラグを設定する必要があります。</p>
+
+<p>以下の例では <code class="plain">http://foo.example</code> から読み込まれた元のコンテンツが、 <code class="plain">http://bar.other</code> にあるリソースに対してクッキーを設定したシンプルな GET リクエストを行います。 foo.example のコンテンツは以下のような JavaScript を含んでいるかもしれません。</p>
+
+<pre class="brush: js notranslate" id="line1">const invocation = new XMLHttpRequest();
+const url = 'http://bar.other/resources/credentialed-content/';
+
+function callOtherDomain() {
+  if (invocation) {
+    invocation.open('GET', url, true);
+    invocation.withCredentials = true;
+    invocation.onreadystatechange = handler;
+    invocation.send();
+  }
+}</pre>
+
+<p>7行目で、クッキー付きで呼び出しを行うために {{domxref("XMLHttpRequest")}} に設定する必要があるフラグ、 <code>withCredentials</code> という真偽値型の値を示しています。既定では、クッキーなしで呼び出しが行われます。これは単純な <code>GET</code> リクエストなのでプリフライトは行いませんが、ブラウザーは {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> ヘッダーを持たないレスポンスを<strong>拒否</strong>し、ウェブコンテンツを呼び出すレスポンスを作成<strong>しない</strong>でしょう。</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/17213/cred-req-updated.png" style="height: 490px; width: 1023px;"></p>
+
+<p>以下はクライアントとサーバーとの間のやりとりの例です。</p>
+
+<pre class="brush: shell notranslate">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: http://foo.example/examples/credential.html
+Origin: http://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]
+</pre>
+
+<p>10行目に <code class="plain">http://bar.other</code> 向けのクッキーが含まれていますが、bar.other が {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> (17行目) をレスポンスに含めなければ、レスポンスは無視されウェブコンテンツで使用できません。</p>
+
+<h4 id="Credentialed_requests_and_wildcards" name="Credentialed_requests_and_wildcards">資格情報付きリクエストとワイルドカード</h4>
+
+<p>資格情報を含むリクエストに対するレスポンスの時、サーバーは <code>Access-Control-Allow-Origin</code> ヘッダーで "<code>*</code>" ワイルドカードではなくオリジンを指定<strong>しなければなりません</strong>。</p>
+
+<p>上記の例のリクエストヘッダーは <code>Cookie</code> ヘッダーを含んでいるため、 <code>Access-Control-Allow-Origin</code> ヘッダーが "*" であったらリクエストは失敗します。 <code>Access-Control-Allow-Origin</code> ヘッダーの値が "<code>*</code>" ワイルドカードではなく "<code class="plain">http://foo.example</code>" (実際のオリジン) なので、ウェブコンテンツの呼び出しに対して資格情報を意識したコンテンツが返ります。</p>
+
+<p>なお、上記の例の中にある <code>Set-Cookie</code> レスポンスヘッダーは、将来のクッキーの設定も行ないます。失敗した場合、 (使われている API によりますが) 例外が発生します。</p>
+
+<h4 id="Third-party_cookies" name="Third-party_cookies">サードパーティーのクッキー</h4>
+
+<p>CORS のレスポンスに設定されたクッキーは、サードパーティーのクッキーに関する通常のポリシーに従います。上記の例では、ページは <code>foo.example</code> から読み込まれていますが、20行目のクッキーは <code>bar.other</code> から送られているので、ユーザーがブラウザーでサードパーティーのクッキーをすべて拒否するよう設定していた場合は保存されません。</p>
+
+<h2 id="The_HTTP_response_headers" name="The_HTTP_response_headers">HTTP レスポンスヘッダー</h2>
+
+<p>ここではオリジン間リソース共有の仕様書で定義されている、アクセス制御のためにサーバーが返す HTTP レスポンスヘッダーを掲載します。前の章では、これらの実際の動作の概要を説明しました。</p>
+
+<h3 id="Access-Control-Allow-Origin">Access-Control-Allow-Origin</h3>
+
+<p>返却されるリソースには、以下のような構文で1つの {{HTTPHeader("Access-Control-Allow-Origin")}} ヘッダーがつくことがあります。</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Origin: &lt;origin&gt; | *
+</pre>
+
+<p><code>Access-Control-Allow-Origin</code> は、リソースへのアクセスを許可するオリジンをブラウザーに伝えるための単一のオリジン、または — 資格情報を<strong>含まない</strong>リクエストにおいては — どのオリジンにもリソースへのアクセスを許可することをブラウザーに伝えるワイルドカード "<code>*</code>" のどちらかを指定することができます。</p>
+
+<p>例えば、 <code>https://mozilla.org</code> のオリジンからのコードにリソースへのアクセスを許可するには、次のように指定します。</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Origin: https://mozilla.org
+Vary: Origin</pre>
+
+<p>サーバーがワイルドカード "<code>*</code>" ではなく (ホワイトリストの一部としてリクエストするオリジンに基づいて動的に変更される可能性がある) 単一のオリジンを指定した場合は、サーバーは {{HTTPHeader("Vary")}} レスポンスヘッダーに <code>Origin</code> も含めて、サーバーのレスポンスが {{HTTPHeader("Origin")}} リクエストヘッダーの値によって変化することをクライアントに示してください。</p>
+
+<h3 id="Access-Control-Expose-Headers">Access-Control-Expose-Headers</h3>
+
+<p>{{HTTPHeader("Access-Control-Expose-Headers")}} ヘッダーは、ブラウザーがアクセスを許可されるサーバーのホワイトリストにあるヘッダーを示すことができます。</p>
+
+<pre class="brush: none notranslate">Access-Control-Expose-Headers: &lt;header-name&gt;[, &lt;header-name&gt;]*
+</pre>
+
+<p>例えば、以下のようになります。</p>
+
+<pre class="brush: none notranslate">Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header
+</pre>
+
+<p>これは、ブラウザーに対して <code>X-My-Custom-Header</code> および <code>X-Another-Custom-Header</code> ヘッダーを許可します。</p>
+
+<h3 id="Access-Control-Max-Age">Access-Control-Max-Age</h3>
+
+<p>このヘッダーはプリフライトリクエストの結果をキャッシュしてよい時間を示します。プリフライトリクエストの例は、前出の例をご覧ください。</p>
+
+<pre class="brush: none notranslate">Access-Control-Max-Age: &lt;delta-seconds&gt;
+</pre>
+
+<p><code>delta-seconds</code> 引数は、結果をキャッシュしてよい時間を秒単位で示します。</p>
+
+<h3 id="Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</h3>
+
+<p>{{HTTPHeader("Access-Control-Allow-Credentials")}} は <code>credentials</code> フラグが真であるときに、リクエストへのレスポンスを開示してよいか否かを示します。プリフライトリクエストのレスポンスの一部として用いられたときは、実際のリクエストで資格情報を使用してよいか否かを示します。単純な <code>GET</code> リクエストはプリフライトを行いませんので、リソースへのリクエストが資格情報付きで行われた場合にリソースと共にこのヘッダーを返さなければ、レスポンスはブラウザーによって無視され、ウェブコンテンツに返らないことに注意してください。</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Credentials: true
+</pre>
+
+<p><a class="internal" href="#Requests_with_credentials">資格情報付きのリクエスト</a>は前に説明したとおりです。</p>
+
+<h3 id="Access-Control-Allow-Methods">Access-Control-Allow-Methods</h3>
+
+<p>{{HTTPHeader("Access-Control-Allow-Methods")}} ヘッダーは、リソースへのアクセス時に許可するメソッドを指定します。これはプリフライトリクエストのレスポンスで用いられます。リクエストのプリフライトを行う条件については前述のとおりです。</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Methods: &lt;method&gt;[, &lt;method&gt;]*
+</pre>
+
+<p>ブラウザーにこのヘッダーを送信する例を含む、プリフライトリクエストの例は <a class="internal" href="#Preflighted_requests">前述のとおりです</a>。</p>
+
+<h3 id="Access-Control-Allow-Headers">Access-Control-Allow-Headers</h3>
+
+<p>{{HTTPHeader("Access-Control-Allow-Headers")}} ヘッダーは、実際のリクエストでどの HTTP ヘッダーを使用できるかを示すために、<a class="internal" href="#Preflighted_requests">プリフライトリクエスト</a>のレスポンスで使用します。</p>
+
+<pre class="brush: none notranslate">Access-Control-Allow-Headers: &lt;header-name&gt;[, &lt;header-name&gt;]*
+</pre>
+
+<h2 id="The_HTTP_request_headers" name="The_HTTP_request_headers">HTTP リクエストヘッダー</h2>
+
+<p>この節では、 HTTP リクエストを発行する際、オリジン間リソース共有機能を利用するためにクライアントが使用できるヘッダーの一覧を掲載します。なお、これらのヘッダーはサーバーの呼び出し時に設定されます。サイト間 {{domxref("XMLHttpRequest")}} の機能を使用する開発者は、オリジン間リソース共有のヘッダーをプログラムで設定する必要はありません。</p>
+
+<h3 id="Origin">Origin</h3>
+
+<p>{{HTTPHeader("Origin")}} ヘッダーはサイト間のアクセスリクエストやプリフライトリクエストのオリジンを示します。</p>
+
+<pre class="brush: none notranslate">Origin: &lt;origin&gt;
+</pre>
+
+<p>origin は、リクエストを開始したサーバーを示す URI です。ここにパス情報は含めず、サーバー名だけにします。</p>
+
+<div class="note"><strong>注:</strong> <code>origin</code> の値は <code>null</code> または URI にすることができます。</div>
+
+<p>すべてのアクセス制御リクエストにおいて、 {{HTTPHeader("Origin")}} ヘッダーは<strong>常に</strong>送信されることに注意してください。</p>
+
+<h3 id="Access-Control-Request-Method">Access-Control-Request-Method</h3>
+
+<p>{{HTTPHeader("Access-Control-Request-Method")}} はプリフライトリクエストを発信する際に、実際のリクエストを行う際に使用する HTTP メソッドをサーバーに知らせるために使用します。</p>
+
+<pre class="brush: none notranslate">Access-Control-Request-Method: &lt;method&gt;
+</pre>
+
+<p>使用例は<a class="internal" href="#Preflighted_requests">前出のとおりです</a>。</p>
+
+<h3 id="Access-Control-Request-Headers">Access-Control-Request-Headers</h3>
+
+<p>{{HTTPHeader("Access-Control-Request-Headers")}} ヘッダーは、プリフライトリクエストを発信する際に、実際のリクエストを行う際に使用する HTTP ヘッダーをサーバーに知らせるために使用します。</p>
+
+<pre class="brush: none notranslate">Access-Control-Request-Headers: &lt;field-name&gt;[, &lt;field-name&gt;]*
+</pre>
+
+<p>使用例は <a class="internal" href="#Preflighted_requests">前出のとおりです</a>。</p>
+
+<h2 id="Specifications" name="Specifications">仕様書</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td>
+   <td>{{Spec2('Fetch')}}</td>
+   <td><a href="https://www.w3.org/TR/cors/">W3C CORS</a> 仕様書を置き換える新しい定義です。</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h2>
+
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p>
+
+<h3 id="Compatibility_notes" name="Compatibility_notes">互換性のメモ</h3>
+
+<p>Internet Explorer 8 および 9 は XDomainRequest オブジェクトで CORS を提供していますが、完全な実装は IE 10 で行っています。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/HTTP/CORS/Errors">CORS のエラー</a></li>
+ <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li>
+ <li>{{domxref("XMLHttpRequest")}}</li>
+ <li><a href="/ja/docs/Web/API/Fetch_API">Fetch API</a></li>
+ <li><a href="https://httptoolkit.tech/will-it-cors">Will it CORS?</a> - an interactive CORS explainer &amp; generator</li>
+ <li><a href="https://www.telerik.com/blogs/using-cors-with-all-modern-browsers">Using CORS with All (Modern) Browsers</a></li>
+ <li><a href="https://alfilatov.com/posts/run-chrome-without-cors/">How to run Chrome browser without CORS</a></li>
+ <li><a href="https://stackoverflow.com/questions/43871637/no-access-control-allow-origin-header-is-present-on-the-requested-resource-whe/43881141#43881141">Stack Overflow のよくある問題を解決するための “how to” 情報</a>
+  <ul>
+   <li>CORS のプリフライトを防止する方法</li>
+   <li>CORS プロキシを使用して<em>「Access-Control-Allow-Origin ヘッダーの欠落」</em>を回避する方法</li>
+   <li><em>「Access-Control-Allow-Origin ヘッダーがワイルドカードを扱えない」</em>ことを修正する方法</li>
+  </ul>
+ </li>
+</ul>