---
schema_version: "1"
id: 6bc94ee50b93ac315b0db0e564f045449383e1c284cf39a389d599ae96ee70a2
title: クロスオリジンリソース共有 (CORS) ポリシー
collection: mulesoft
version: current
locale: ja-jp
portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/mule-gateway/policies-included-cors.md
canonical_url: https://docs.mulesoft.com/jp/mule-gateway/policies-included-cors
source_site: docs.mulesoft.com
content_type: documentation
content_hash: c37081e81f4fca5b0ef544c10587939d2a0a0bbdd1f2cd1cc119519133e40f8a
description: MuleSoft Documentation Site
latest: true
---
# クロスオリジンリソース共有 (CORS) ポリシー

<table class="tableblock frame-all grid-all fit-content spread">
<colgroup>
<col>
<col>
</colgroup>
<tbody>
<tr>
<td class="tableblock halign-right valign-top"><p class="tableblock"><strong>ポリシー名</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>クロスオリジンリソース共有 (CORS)</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-right valign-top"><p class="tableblock"><strong>概要</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>外部ドメインに存在するリソースへのアクセスを可能にする</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-right valign-top"><p class="tableblock"><strong>カテゴリ</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>コンプライアンス</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-right valign-top"><p class="tableblock"><strong>使用可能な最小 Mule バージョン</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>v4.1.1</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-right valign-middle"><p class="tableblock"><strong>返される状況コード</strong></p></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>このポリシーの戻りコードは存在しません</p>
</div></div></td>
</tr>
</tbody>
</table>

## [](#概要)概要

CORS は、Web アプリケーションが別のドメインで定義されたリソースにアクセスできるメカニズムです。ブラウザーは、この標準をデフォルトで実装しています。CORS ポリシーは [「CORS W3C Recommendation (CORS W3C 勧告)」](https://fetch.spec.whatwg.org/)​の標準に準拠します。

## [](#ポリシーのパラメーターの設定)ポリシーのパラメーターの設定

### [](#mule-ゲートウェイ)Mule ゲートウェイ

UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。

<table class="tableblock frame-all grid-all fit-content spread">
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th class="tableblock halign-left valign-top">要素</th>
<th class="tableblock halign-left valign-top">説明</th>
<th class="tableblock halign-left valign-top">必須?</th>
</tr>
</thead>
<tbody>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Public resource (公開リソース)</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>CORS 設定を公開リソースとして適用するかどうか (デフォルト)。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>はい</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Default group (デフォルトグループ)</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>CORS 設定を特定のリソースにのみ適用するかどうか (​<strong>[Public resource (公開リソース)]</strong>​ を選択解除する必要があります)</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>いいえ</p>
</div></div></td>
</tr>
<tr>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>Support credentials (ログイン情報のサポート)</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうか。</p>
</div></div></td>
<td class="tableblock halign-left valign-top"><div class="content"><div class="paragraph">
<p>いいえ</p>
</div></div></td>
</tr>
</tbody>
</table>

## [](#非-api-ゲートウェイ-mule-環境の-cors-の設定)非 API ゲートウェイ Mule 環境の CORS の設定

Mule Runtime Engine (Mule) が API ゲートウェイ機能で有効になっておらず、CORS 機能を実装する必要がある場合、CORS インターセプターを使用できます。CORS インターセプターは、Mule 4.0 で使用可能になった HTTP リスナー設定の要素です。

CORS 設定は、CORS ポリシー機能を公開リソースとして利用するか、選択したオリジングループ用として利用するかによって異なります。

次の例は、選択したオリジングループ構造の設定可能な要素を示しています。

```XML
<http:listener-interceptors>
   <http:cors-interceptor allowCredentials="optional boolean value (true/false)">
       <http:origins> (collection of origins)
           <http:origin url="http://origin.com" accessControlMaxAge="integer value">
               <http:allowed-methods>
                   <http:method methodName="method 1"/>
	    ...
                   <http:method methodName="method n"/>
               </http:allowed-methods>
               <http:allowed-headers>
                   <http:header headerName="header 1"/>
 	    ...
                   <http:header headerName="header n"/>
               </http:allowed-headers>
               <http:expose-headers>
                   <http:header headerName="header 1"/>
	    ...
                   <http:header headerName="header n"/>
               </http:expose-headers>
           </http:origin>
       </http:origins>
   </http:cors-interceptor>
</http:listener-interceptors>
```

次の例は、公開リソース構造の設定可能な要素を示しています。

```XML
<http:listener-interceptors>
   <http:cors-interceptor allowCredentials="optional boolean value (true/false)">
       <http:origins>
           <http:public-resource/>
       </http:origins>
   </http:cors-interceptor>
</http:listener-interceptors>
```

## [](#cors-を使用する理由)CORS を使用する理由

CORS により、お使いの環境で Web ページのセキュリティと Web の整合性を実現できます。CORS ポリシーをバックエンドに適用する必要がある理由を知るには、まず​_オリジン_​と ​_Cookie_​ の働きと、これらを操作して Web ページの整合性が損なわれる仕組みについて理解する必要があります。

### [](#origins)Web オリジンの概念

オリジンとは、フェッチを開始した要求を指定するヘッダーです。オリジンヘッダーにはサーバー名のみが含まれます (パス情報は含まれません)。非常に基本的なレベルでは、オリジンは以下から構成されます。

- URI スキーム: `http://`
- ホスト名: `www.example.com`
- ポート番号: `8080`

2 つの​[オリジン](#origins)​の間で要求を承認させるには、それらのオリジンが等しくなければなりません。これら 3 つのパラメーターがすべて一致した場合にのみ、オリジンは等しいと見なされます。詳細は、 [「RFC 6454 - The Web Origin Concept (Web オリジンの概念)」](https://tools.ietf.org/html/rfc6454)​を参照してください。

### [](#http-cookie)HTTP Cookie

Web サイトでは HTTP Cookie を使用してステートフルな情報を維持しています。最も一般的な例として、Web サーバーは認証 Cookie を使用して、ユーザーがログインしているかどうかと、ユーザーがログインしているアカウントを判断します。詳細は、 [RFC 6265](https://www.ietf.org/rfc/rfc6265.txt)​ を参照してください。

SOP (同一オリジンポリシー) は、1 つの Web ページから別のページを呼び出すときに悪意のある攻撃者による Cookie の不正利用を抑止します。たとえば、銀行の Web ページに Cookie を使用してログインした場合、攻撃者はその Cookie を不正に取得して、正規ユーザーになりすまして銀行の API に対してクエリを実行しようと試みます。

SOP を使用している場合、対象 Web ページのオリジンが呼び出し側の Web ページのオリジンと同じである場合にのみ、対象 Web ページのデータへのアクセスが許可されます。オリジンの詳細については、 [Wikipedia](https://en.wikipedia.org/wiki/Same-origin_policy)​ を参照してください。

次の例は、Web ページ ​`http://www.example.com:8080`​ のオリジンを示しています。

![結果や理由を含め、URL 比較結果を示すテーブル](/mulesoft/current/ja-jp/mule-gateway/_images/cors-policy-sop-example.png)

SOP は非常に制約が厳しいため、Web ページ上では、1 つのサブオリジンから別のサブオリジンや外部のハイパーリンクにはアクセスできません。たとえば、オリジン ​`www.testapply.com`​ に 2 つのサブオリジン ​`www.eng.testapply.com`​ および ​`www.docs.testapply.com`​ がある場合、これらのサブオリジン間の通信は拒否されます。さらに、各サブオリジンから外部 Web サイトへのハイパーリンクも拒否されます。

この問題を回避するため、Web ブラウザーでは CORS 標準を実装しており、この標準に従って Web サーバーを検証し、検証に成功すれば要求を受け入れるようにしています。

たとえば、銀行のログインサーバーで CORS サーバー側プロトコルが実装されている場合は、銀行の Web ページから直接クエリを実行しなければデータにはアクセスできません。外部の (銀行以外の) ドメインからログイン API に対してクエリを実行しても拒否されます。

## [](#cors-の仕組み)CORS の仕組み

Web ページがデータを要求すると、ブラウザーは要求が同じオリジンから出されているかどうかを検出して、CORS アルゴリズムを適用するかどうかを決定します。オリジンとは違う Web ページからデータのクエリを実行した場合は、CORS ポリシーが適用されます。

CORS アルゴリズムは、情報を要求した Web ページに対して Web サーバー上とクライアント側で実行されます。CORS ポリシーのクライアント側のアルゴリズムは次のように実装されます。

- 要求が複雑 (そして潜在的に危険) であるかどうかを判断し、事前の​_プリフライト_​要求を送信して、サーバーがオリジンを受け入れるかどうかを検証する。
- 実際の要求を実行し、サーバーが正しく応答してオリジンを受け入れることを検証する。

_プリフライト_​とは Web ブラウザーからバックエンドサーバーに送信される (HTTP メソッドとして OPTIONS を使用した) 事前要求であり、要求を実行しようとしている Web ページのアイデンティティ (オリジンと他のいくつかのヘッダー) をテストします。

バックエンドがオリジンを受け入れない場合、バックエンドサーバーは特定のヘッダー (Access-Control-Allow-Origin) なしで要求に応答します。これによってクライアントは、そのサーバーではページのオリジンが許可されないことを理解して、実際の要求を実行しません。

次の図は、実際の要求を実行するかどうかを決定する JavaScript フローの XMLHttpRequest (XHR) を示しています。

![Javascript クロスドメイン XHR コールの標準レイテンシーと追加レイテンシーのプロセスを示すフローチャート](/mulesoft/current/ja-jp/mule-gateway/_images/cors-policy-xhr-diagram.png)

図に示されているように、ブラウザーとサーバーとの間の通信に基づいて要求が検証されます。

- 要求が複雑であると見なされた場合は (上記の XHR のクライアント側の図参照)、プリフライト要求が実行されます。
    
    サーバーがプリフライトに対して適切なレスポンスヘッダーを返さない場合、クライアントライブラリ (上の例では XHR) は実際の要求を実行できません。
- プリフライトに対して正しく完全な応答が返された場合、クライアントライブラリは特定の CORS ヘッダーを含む実際の要求を実行します。
    
    そしてクライアントライブラリは応答の CORS ヘッダーを検証します。いずれかの必須ヘッダーが欠落している場合、クライアントライブラリは再び、要求がクライアント (通常は Web ページ) に到達しないようにブロックする必要があります。

## [](#cors-のコンポーネント)CORS のコンポーネント

リクエストヘッダー、レスポンスヘッダー、公開リソースとグループ、順序、ワイルドカードなど、CORS ポリシーのさまざまなコンポーネントを設定できます。

### [](#cors-リクエストヘッダー)CORS リクエストヘッダー

- Origin: クロスオリジン要求を実行するオリジン。
- Access-Control-Request-Method: 実際の要求で呼び出されるメソッド。
    
    このヘッダーは、プリフライト要求で送信されます。
- Access-Control-Request-Headers: 実際の要求で送信されるカスタムヘッダー。
    
    このヘッダーは、プリフライト要求で送信されます。GET メソッドと HEAD メソッドに対しては、シンプルであるためプリフライトを必要としないヘッダーのリストが標準によって定義されています。カスタムヘッダーに対しては、GET 要求と HEAD 要求でプリフライトが実行されます (クライアントがプリフライトを実行する必要のないパスの検証については、上記の XHR の例を参照してください)。

### [](#cors-レスポンスヘッダー)CORS レスポンスヘッダー

応答に含まれるヘッダーは、要求がプリフライトまたは実際の要求のどちらであるかによって異なります。

- `Access-Control-Allow-Origin`​: すべての応答で必須。
    
    このヘッダーが応答に含まれていない場合、ブラウザーやクライアントライブラリは応答が Web ページに到達しないようにブロックします。ワイルドカードの「\*」を使用して任意のオリジンを表すことができます。
- `Access-Control-Allow-Methods`​: 実行が許可されているメソッド。
    
    このヘッダーは、OPTIONS 要求で返されます。サーバーは、許可されるメソッドのリストを応答で返し、検証をクライアントに委任する場合があります。
- `Access-Control-Allow-Headers`​: 実際の要求で許可されるヘッダー。
    
    このヘッダーは、Access-Control-Allow-Methods と同じように機能します。
- `Access-Control-Allow-Credentials`​: Cookie を使用して実際の要求を実行できるかどうかをクライアントに通知します。
    
    `Access-Control-Allow-Credentials`​ はブール値を返します。
- `Access-Control-Expose-Headers`​: 要求を実行した Web ページがアクセスできるヘッダーのリストをブラウザーまたはクライアントライブラリに提供します。
    
    CORS 要求を実行している HTTP ライブラリは、ヘッダーのみを Web ページに提供することで、プライバシーとセキュリティを強化します。
- `Access-Control-Max-Age`​: ブラウザーが要求に対する 2 回目のプリフライトの実行を回避できる期間 (秒数) を指定します。

### [](#公開リソースとグループ)公開リソースとグループ

ブラウザー SOP をバイパスする必要がある場合に備えて、MuleSoft では公開リソースを設定するためのオプションを用意しており、応答に含まれるプリフライトデータを API ゲートウェイポリシーに反映できるようにしています。これにより、すべての CORS ヘッダーで実際の要求が正しく更新され、ブラウザーは応答を受け入れます。

お使いの環境において、公開リソースオプションでは十分な安全性を確保できない場合には、API に対してクエリを実行する異なるオリジンに対して複数のグループを定義してください。各グループはオリジンのリストに適用され、グループごとに異なるメソッド、ヘッダー、プリフライトキャッシュ時間、ヘッダー公開設定を指定できます。

### [](#順序)順序

CORS ポリシーは API ゲートウェイによって常に最初に適用され、その後に他のポリシーが適用できるようになります。CORS ポリシーが適用されているアプリケーションに OPTIONS を使用している保護された要求が送信された場合、要求は保護されたリソースに到達しません。 [CORS 仕様](https://fetch.spec.whatwg.org/#resource-preflight-requests)​に従い、すべての OPTIONS 要求はプリフライトとみなされます。

### [](#設定ワイルドカード)設定ワイルドカード

グループ設定のオリジンセクションとヘッダーセクションではワイルドカード (​`*`​) を使用できます。ワイルドカードは、公開リソースが必要でありながらも、受け入れられる HTTP メソッドを制限する必要がある場合に使用します。

複数のグループを設定してあり、いずれかのグループでワイルドカードを使用してオリジンを指定してある場合、ワイルドカードを使用していない設定の方がワイルドカードによる指定よりも優先されます。

## [](#faqs)FAQs

**CORS ポリシーが適用されていないようです。**

curl や Postman などのツールを使用して複雑な要求の CORS ポリシーをテストすると、CORS リクエストヘッダーが追加されず、プリフライトが実行されません。

要求で CORS ヘッダーが送信されないか、不適切なヘッダーが使用されていると、API ゲートウェイ CORS ポリシーは CORS レスポンスヘッダーを追加しません。これはポリシーが適用されないことを意味します。ライブラリで環境に適した CORS プロトコルが実装されていること、または仕様で正しいヘッダーを設定していることを確認してください。