[〜#〜] mdn [〜#〜] は、Cookie、認証ヘッダー、TLSクライアント証明書などの資格情報をサイト間で交換する必要がある場合、Access-Control-Allow-Crendentials
をtrue
に設定する必要があることを示しています。
2つのサイトA --- https://example1.xyz.com ともう1つのサイトB- https://example2.xyz.com を考えてみましょう。ここで、AからBにhttpGet
リクエストを送信する必要があります。AからBをリクエストすると、次のようになります。
「要求されたリソースに「Access-Control-Allow-Origin」ヘッダーがありません。したがって、「Origin」 http://example1.xyz.com 'はアクセスを許可されていません。」
そこで、Bに次の応答ヘッダーを追加します
response.setHeader("Access-Control-Allow-Origin", request.getHeader("Origin"));
これにより、同一生成元エラーが解決され、Bにリクエストできます。いつ、なぜ設定する必要がありますか
response.setHeader("Access-Control-Allow-Credentials", "true");
このsame-Origin
エラーを解決するためにグーグルで検索したとき、それらのほとんどは両方のヘッダーを使用することを推奨しました。 2番目のAccess-Control-Allow-Credentials
の使用についてはよくわかりません。
Access-Control-Allow-Origin
ではなく、リクエストヘッダーから取得したOrigin
に*
を設定する必要があるのはなぜですか?それをよりよく理解するために例を引用してください。
Allow-リクエストでCookieも送信できるようにする場合は、認証情報が必要になります。着信要求を承認する必要がある場合は、セッションIDCookieに基づいて行うのが一般的な理由です。
ワイルドカードを設定すると、どのサイトでもエンドポイントにリクエストを送信できます。リクエストが定義したホワイトリストと一致する場合、Originにallowを設定するのが一般的です。一部のブラウザは許可応答をキャッシュします。別のドメインからも同じコンテンツをリクエストした場合、リクエストが拒否される可能性があります。
ワイルドカード
Access-Control-Allow-Origin
ではなくリクエストヘッダーから取得した*
をOrigin
に設定する必要があるのはなぜですか?
自分が何をしているのか非常に確信が持てない限り、そうすべきではありません。
次の場合は実際に安全です。
たとえば、サーバーコードが、ユーザーの便宜のためにアプリケーションの状態またはセッションの状態を保存する目的でCookieを設定しているだけの場合、Origin
リクエストヘッダーの値を取得して反映するリスクはありません。 Access-Control-Allow-Origin
応答ヘッダーも送信しながら、それをAccess-Control-Allow-Credentials: true
値にエコーバックします。
一方、設定しているCookieが機密情報や機密データを公開している場合は、他の方法でロックされていることが本当に確実でない限り(どういうわけか…)、Origin
を反映しないようにします。 Access-Control-Allow-Origin
を送信しながら、(サーバー側でチェックせずに)Access-Control-Allow-Credentials: true
値に入力します。
これを行うと、悪意のある攻撃者がアクセスできるような方法で機密情報や機密データが公開される可能性があります。リスクの説明については、以下をお読みください。
また、CORSヘッダーを送信するリソースがnotである場合、誰もがアクセスできるように意図されたパブリックサイトまたはAPIエンドポイントではなく、イントラネット内にあります。または、IPアドレスが制限されたファイアウォールの背後にある場合は、Access-Control-Allow-Origin
-reflects -Origin
とAccess-Control-Allow-Credentials: true
の組み合わせを絶対に避けたいと思うでしょう。 (イントラネットの場合、ほとんどの場合、特定のハードコードされた/ホワイトリストに登録されたオリジンのみを許可する必要があります。)
Access-Control-Allow-Credentials: true
を設定すると、実際には2つの効果があります。
Set-Cookie
応答ヘッダーを発生させます 実際にはCookieを設定する効果があります (それ以外の場合はSet-Cookie
応答ヘッダーは無視されます)これらの効果は、設定 XMLHttpRequest.withCredentials
または credentials: 'include'
(Fetch API)が 資格情報(HTTP Cookie、TLS)を引き起こす効果と組み合わされますクライアント証明書、および認証エントリ) 実際にリクエストの一部として含まれます。
https://fetch.spec.whatwg.org/#example-cors-with-credentials Fetch仕様には良い例があります