クロスオリジンリソース共有 (CORS) ポリシー
ポリシー名 |
クロスオリジンリソース共有 (CORS) |
概要 |
外部ドメインに存在するリソースへのアクセスを可能にする |
カテゴリ |
コンプライアンス |
使用可能な最小 Mule バージョン |
v4.1.1 |
返される状況コード |
このポリシーの戻りコードは存在しません |
概要
CORS は、Web アプリケーションが別のドメインで定義されたリソースにアクセスできるメカニズムです。ブラウザーは、この標準をデフォルトで実装しています。CORS ポリシーは 「CORS W3C Recommendation (CORS W3C 勧告)」の標準に準拠します。
ポリシーのパラメーターの設定
Mule ゲートウェイ
UI からポリシーを API に適用するときに、以下のパラメーターが表示されます。
| 要素 | 説明 | 必須? |
|---|---|---|
Public resource (公開リソース) |
CORS 設定を公開リソースとして適用するかどうか (デフォルト)。 |
はい |
Default group (デフォルトグループ) |
CORS 設定を特定のリソースにのみ適用するかどうか ([Public resource (公開リソース)] を選択解除する必要があります) |
いいえ |
Support credentials (ログイン情報のサポート) |
ポリシーが Cookie、認証ヘッダー、TLS クライアント証明書などのログイン情報をサポートするかどうか。 |
いいえ |
非 API ゲートウェイ Mule 環境の CORS の設定
Mule Runtime Engine (Mule) が API ゲートウェイ機能で有効になっておらず、CORS 機能を実装する必要がある場合、CORS インターセプターを使用できます。CORS インターセプターは、Mule 4.0 で使用可能になった HTTP リスナー設定の要素です。
CORS 設定は、CORS ポリシー機能を公開リソースとして利用するか、選択したオリジングループ用として利用するかによって異なります。
次の例は、選択したオリジングループ構造の設定可能な要素を示しています。
<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>次の例は、公開リソース構造の設定可能な要素を示しています。
<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 により、お使いの環境で Web ページのセキュリティと Web の整合性を実現できます。CORS ポリシーをバックエンドに適用する必要がある理由を知るには、まずオリジンと Cookie の働きと、これらを操作して Web ページの整合性が損なわれる仕組みについて理解する必要があります。
Web オリジンの概念
オリジンとは、フェッチを開始した要求を指定するヘッダーです。オリジンヘッダーにはサーバー名のみが含まれます (パス情報は含まれません)。非常に基本的なレベルでは、オリジンは以下から構成されます。
-
URI スキーム:
http:// -
ホスト名:
www.example.com -
ポート番号:
8080
2 つのオリジンの間で要求を承認させるには、それらのオリジンが等しくなければなりません。これら 3 つのパラメーターがすべて一致した場合にのみ、オリジンは等しいと見なされます。詳細は、 「RFC 6454 - The Web Origin Concept (Web オリジンの概念)」を参照してください。
HTTP Cookie
Web サイトでは HTTP Cookie を使用してステートフルな情報を維持しています。最も一般的な例として、Web サーバーは認証 Cookie を使用して、ユーザーがログインしているかどうかと、ユーザーがログインしているアカウントを判断します。詳細は、 RFC 6265 を参照してください。
SOP (同一オリジンポリシー) は、1 つの Web ページから別のページを呼び出すときに悪意のある攻撃者による Cookie の不正利用を抑止します。たとえば、銀行の Web ページに Cookie を使用してログインした場合、攻撃者はその Cookie を不正に取得して、正規ユーザーになりすまして銀行の API に対してクエリを実行しようと試みます。
SOP を使用している場合、対象 Web ページのオリジンが呼び出し側の Web ページのオリジンと同じである場合にのみ、対象 Web ページのデータへのアクセスが許可されます。オリジンの詳細については、 Wikipedia を参照してください。
次の例は、Web ページ http://www.example.com:8080 のオリジンを示しています。
SOP は非常に制約が厳しいため、Web ページ上では、1 つのサブオリジンから別のサブオリジンや外部のハイパーリンクにはアクセスできません。たとえば、オリジン www.testapply.com に 2 つのサブオリジン www.eng.testapply.com および www.docs.testapply.com がある場合、これらのサブオリジン間の通信は拒否されます。さらに、各サブオリジンから外部 Web サイトへのハイパーリンクも拒否されます。
この問題を回避するため、Web ブラウザーでは CORS 標準を実装しており、この標準に従って Web サーバーを検証し、検証に成功すれば要求を受け入れるようにしています。
たとえば、銀行のログインサーバーで CORS サーバー側プロトコルが実装されている場合は、銀行の Web ページから直接クエリを実行しなければデータにはアクセスできません。外部の (銀行以外の) ドメインからログイン API に対してクエリを実行しても拒否されます。
CORS の仕組み
Web ページがデータを要求すると、ブラウザーは要求が同じオリジンから出されているかどうかを検出して、CORS アルゴリズムを適用するかどうかを決定します。オリジンとは違う Web ページからデータのクエリを実行した場合は、CORS ポリシーが適用されます。
CORS アルゴリズムは、情報を要求した Web ページに対して Web サーバー上とクライアント側で実行されます。CORS ポリシーのクライアント側のアルゴリズムは次のように実装されます。
-
要求が複雑 (そして潜在的に危険) であるかどうかを判断し、事前のプリフライト要求を送信して、サーバーがオリジンを受け入れるかどうかを検証する。
-
実際の要求を実行し、サーバーが正しく応答してオリジンを受け入れることを検証する。
プリフライトとは Web ブラウザーからバックエンドサーバーに送信される (HTTP メソッドとして OPTIONS を使用した) 事前要求であり、要求を実行しようとしている Web ページのアイデンティティ (オリジンと他のいくつかのヘッダー) をテストします。
バックエンドがオリジンを受け入れない場合、バックエンドサーバーは特定のヘッダー (Access-Control-Allow-Origin) なしで要求に応答します。これによってクライアントは、そのサーバーではページのオリジンが許可されないことを理解して、実際の要求を実行しません。
次の図は、実際の要求を実行するかどうかを決定する JavaScript フローの XMLHttpRequest (XHR) を示しています。
図に示されているように、ブラウザーとサーバーとの間の通信に基づいて要求が検証されます。
-
要求が複雑であると見なされた場合は (上記の XHR のクライアント側の図参照)、プリフライト要求が実行されます。
サーバーがプリフライトに対して適切なレスポンスヘッダーを返さない場合、クライアントライブラリ (上の例では XHR) は実際の要求を実行できません。
-
プリフライトに対して正しく完全な応答が返された場合、クライアントライブラリは特定の CORS ヘッダーを含む実際の要求を実行します。
そしてクライアントライブラリは応答の CORS ヘッダーを検証します。いずれかの必須ヘッダーが欠落している場合、クライアントライブラリは再び、要求がクライアント (通常は Web ページ) に到達しないようにブロックする必要があります。
CORS のコンポーネント
リクエストヘッダー、レスポンスヘッダー、公開リソースとグループ、順序、ワイルドカードなど、CORS ポリシーのさまざまなコンポーネントを設定できます。
CORS リクエストヘッダー
-
Origin: クロスオリジン要求を実行するオリジン。
-
Access-Control-Request-Method: 実際の要求で呼び出されるメソッド。
このヘッダーは、プリフライト要求で送信されます。
-
Access-Control-Request-Headers: 実際の要求で送信されるカスタムヘッダー。
このヘッダーは、プリフライト要求で送信されます。GET メソッドと HEAD メソッドに対しては、シンプルであるためプリフライトを必要としないヘッダーのリストが標準によって定義されています。カスタムヘッダーに対しては、GET 要求と HEAD 要求でプリフライトが実行されます (クライアントがプリフライトを実行する必要のないパスの検証については、上記の XHR の例を参照してください)。
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 仕様に従い、すべての OPTIONS 要求はプリフライトとみなされます。