Access-Control-Allow-Originを設定することのセキュリティ上のリスクは何ですか？
私は最近Access-Control-Allow-Originから*クロスサブドメインのAjax呼び出しを行えるようにするため。
今、自分の環境をセキュリティリスクにさらしていると感じざるを得ません。
間違っている場合は手伝ってください。
Access-Control-Allow-Origin: *で応答することにより、要求されたリソースはすべてのOriginと共有できます。これは基本的に、どのサイトもあなたのサイトにXHRリクエストを送信し、サーバーのレスポンスにアクセスできることを意味します。これは、このCORSレスポンスを実装していない場合には当てはまりません。
したがって、どのサイトでも訪問者に代わってサイトにリクエストを行い、そのレスポンスを処理できます。ブラウザによって自動的に提供されるもの（Cookie、Cookieベースのセッションなど）に基づく認証または承認スキームのようなものを実装している場合、サードパーティのサイトによってトリガーされた要求もそれらを使用します。
これは確かに、特に選択したリソースだけでなくすべてのリソースに対してリソース共有を許可する場合、セキュリティ上のリスクをもたらします。このコンテキストでは、CORSを有効にするのは安全ですか？を確認する必要があります。
Access-Control-Allow-Origin: *は、任意のリソースに追加してもまったく安全ですunlessそのリソースには、標準の資格情報（Cookie、基本認証）以外で保護されたプライベートデータが含まれます、TLSクライアント証明書）。
例：Cookieで保護されたデータは安全です
https://example.com/users-private-dataを想像してください。これは、ユーザーのログイン状態に応じてプライベートデータを公開する場合があります。この状態はセッションCookieを使用します。このヘッダーは、Cookieなしでリクエストが行われ、プライベートデータを取得するためにCookieが必要な場合にのみ応答にアクセスできるため、このリソースにAccess-Control-Allow-Origin: *を追加することはsafeです。その結果、個人データが漏洩することはありません。
例：ロケーション/ IP /内部ネットワークで保護されたデータは安全ではありません（残念ながらイントラネットや家電製品では一般的です）：
会社の個人データを公開するhttps://intranet.example.com/company-private-dataを想像してください。ただし、会社のWi-Fiネットワーク上にいる場合にのみアクセスできます。このリソースにAccess-Control-Allow-Origin: *を追加するのは安全ではないです。標準の資格情報以外を使用して保護されているためです。そうしないと、不正なスクリプトによってイントラネットへのトンネルとして使用される可能性があります。
経験則
シークレットウィンドウでリソースにアクセスした場合にユーザーに表示されるものを想像してください。このコンテンツ（ブラウザが受け取ったソースコードを含む）を見て満足している場合は、Access-Control-Allow-Origin: *を追加しても安全です。
知る限りでは、Access-Control-Allow-Originは、サーバーからブラウザに送信される単なるhttpヘッダーです。特定のアドレスに制限する（または無効にする）と、ロボットなどのサイトの安全性は向上しません。ロボットが必要な場合は、ヘッダーを無視できます。そこにある通常のブラウザ（Explorer、Chromeなど）は、デフォルトでヘッダーを尊重します。しかし、 Postman のようなアプリケーションは単に無視します。
サーバーエンドは、応答を返すときに、要求の「起源」が何であるかを実際にはチェックしません。 HTTPヘッダーを追加するだけです。リクエストを送信したのはブラウザ（クライアントエンド）であり、アクセス制御ヘッダーを読み取って処理することを決定します。 XHRの場合、特別な「OPTIONS」リクエストを使用してヘッダーを最初に要求することに注意してください。
そのため、創造的なスクリプト作成機能を備えたユーザーは、ヘッダーに設定されているものは何でも簡単に無視できます。
Access-Control-Allow-Originの設定のセキュリティ問題の可能性 も参照してください。
では実際に質問に答えましょう
私は自分の環境をセキュリティリスクにさらしていると感じずにはいられません。
誰かがあなたを攻撃したい場合は、Access-Control-Allow-Originを簡単にバイパスできます。ただし、「*」を有効にすると、HTTPヘッダーを尊重する通常のWebブラウザーを使用するなど、攻撃者に「攻撃ベクトル」をさらに与えることができます。
ワイルドカードに本当に問題がある場合、コメントとして投稿された2つの例を次に示します。
銀行のウェブサイトにログインするとします。別のページに移動してから銀行に戻ると、Cookieが原因でログインしたままです。インターネット上の他のユーザーは、私の銀行で私と同じURLにアクセスできますが、Cookieなしでは私のアカウントにアクセスできません。クロスオリジンリクエストが許可されている場合、悪意のあるWebサイトがユーザーになりすますことができます。
– ブラッド
Linksys WRT54gなどの一般的なホームルーターがあるとします。ルーターがクロスオリジン要求を許可すると仮定します。私のWebページのスクリプトは、一般的なルーターIPアドレス（192.168.1.1など）にHTTP要求を行い、攻撃を許可するようにルーターを再構成できます。ルーターをDDoSノードとして直接使用することもできます。 （ほとんどのルーターには、pingまたは単純なHTTPサーバーチェックを可能にするテストページがあります。これらはまとめて悪用される可能性があります。）
– ブラッド
実際の例で問題を説明しているので、これらのコメントは答えだったはずだと思います。