最近、クロスサブドメインのajax呼び出しを行うことができるように設定Access-Control-Allow-Originする*必要がありました。
今、私は自分の環境をセキュリティリスクにさらしていると感じざるを得ません。
私がそれを間違えているなら助けてください。

で応答することによりAccess-Control-Allow-Origin: *、要求されたリソースはすべてのオリジンとの共有を許可します。これは基本的に、どのCORS応答も実装していなかった場合、XHRリクエストをサイトに送信してサーバーの応答にアクセスできることを意味します。

そのため、どのサイトでも、訪問者に代わってサイトにリクエストを送信し、その応答を処理できます。ブラウザーによって自動的に提供されるもの（Cookie、Cookieベースのセッションなど）に基づく認証または承認スキームのようなものを実装している場合、サードパーティのサイトによってトリガーされるリクエストもそれらを使用します。

これは確かに、特に選択したリソースだけでなくすべてのリソースに対してリソース共有を許可する場合に、セキュリティ上のリスクをもたらします。このコンテキストでは、いつCORSを有効にしても安全ですか？。

Access-Control-Allow-Origin: *リソースに標準の資格情報（Cookie、基本認証、TLSクライアント証明書）以外のもので保護されたプライベートデータが含まれていない限り、リソースに追加しても完全に安全です。

例：Cookieで保護されたデータは安全です

想像してみてくださいhttps://example.com/users-private-data。ユーザーのログイン状態によってはプライベートデータが公開される可能性があります。この状態はセッションCookieを使用します。それはだ、安全追加するAccess-Control-Allow-Origin: *要求は、クッキーなしで行われている場合は、このヘッダにのみ応答へのアクセスを可能にするように、このリソースに、そしてクッキーはプライベートなデータを取得するために必要とされます。その結果、個人情報が漏洩することはありません。

例：場所/ IP /内部ネットワークで保護されたデータは安全ではありません（残念ながらイントラネットや家電では一般的です）：

想像してくださいhttps://intranet.example.com/company-private-data。これは、会社のプライベートデータを公開しますが、会社のWi-Fiネットワークを使用している場合にのみアクセスできます。このリソースは標準の資格情報以外のものを使用して保護されているため、このリソースに追加するのは安全ではありませんAccess-Control-Allow-Origin: *。さもなければ、悪いスクリプトがイントラネットへのトンネルとしてあなたを使うかもしれません。

経験則

シークレットウィンドウでリソースにアクセスした場合にユーザーに表示される画像を想像してみてください。このコンテンツ（ブラウザが受け取ったソースコードを含む）をすべての人に見て満足している場合は、追加しても安全Access-Control-Allow-Origin: *です。

AFAIK、Access-Control-Allow-Originは、サーバーからブラウザーに送信される単なるhttpヘッダーです。特定のアドレスに制限（または無効化）しても、ロボットなどのサイトの安全性は向上しません。ロボットが望むなら、彼らはヘッダーを無視することができます。通常のブラウザー（Explorer、Chromeなど）は、デフォルトでヘッダーを受け入れます。しかし、Postmanのようなアプリケーションは単にそれを無視します。

サーバー側は、応答を返すときに、要求の「起点」が何であるかを実際には確認しません。httpヘッダーを追加するだけです。アクセス制御ヘッダーを読み取ってそれに基づいて動作することを決定するのは、リクエストを送信したブラウザー（クライアント側）です。XHRの場合、最初にヘッダーを要求するために特別な「OPTIONS」リクエストを使用する場合があることに注意してください。

したがって、創造的なスクリプト作成機能を持つ人は、ヘッダーに設定されているものは何でも、ヘッダー全体を簡単に無視できます。

Access-Control-Allow-Originの設定で起こり得るセキュリティの問題も参照してください。

今実際に質問に答えるために

私は自分の環境をセキュリティリスクにさらしていると感じざるを得ません。

誰かがあなたを攻撃したい場合、彼らは簡単にAccess-Control-Allow-Originをバイパスできます。しかし、「*」を有効にすることで、HTTPヘッダーを尊重する通常のWebブラウザーを使用するなど、攻撃者にさらにいくつかの「攻撃ベクトル」を与えることができます。

ワイルドカードが本当に問題である場合、コメントとして投稿された2つの例を次に示します。

銀行のWebサイトにログインするとします。別のページに移動してから銀行に戻ると、Cookieが原因でまだログインしています。インターネット上の他のユーザーは私と同じように私の銀行で同じURLにアクセスできますが、Cookieがないと私のアカウントにアクセスできません。クロスオリジンリクエストが許可されている場合、悪意のあるWebサイトがユーザーになりすますことができます。

– ブラッド

Linksys WRT54gなどの一般的なホームルーターがあるとします。ルーターがクロスオリジンリクエストを許可するとします。私のWebページのスクリプトは、一般的なルーターのIPアドレス（192.168.1.1など）にHTTP要求を送信し、攻撃を許可するようにルーターを再構成できます。ルーターを直接DDoSノードとして使用することもできます。（ほとんどのルーターには、pingまたは単純なHTTPサーバーチェックを可能にするテストページがあります。これらはまとめて悪用される可能性があります。）

–ブラッド

これらのコメントは実際の例で問題を説明しているので、これらのコメントは答えである必要があると思います。

サーバーがヘッダーの下に設定することでCORSを完全に無効にしようとするシナリオ。

• Access-Control-Allow-Origin：*（サーバーが任意のORIGINからのクロスサイト要求を受け入れることをブラウザーに通知します）

• Access-Control-Allow-Credentials：true（クロスサイト要求がCookieを送信できることをブラウザーに通知します）

ブラウザに実装されているフェイルセーフにより、以下のエラーが発生します

"Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’"

したがって、ほとんどのシナリオでは、「Access-Control-Allow-Origin」を *に設定しても問題ありません。ただし、攻撃から保護するために、サーバーは許可されたオリジンのリストを維持でき、サーバーがクロスオリジン要求を受信するたびに、許可されたオリジンのリストに対してORIGINヘッダーを検証し、Access-Control-Allow-Originで同じメッセージをエコーバックできます。ヘッダ。

ORIGINヘッダーはブラウザーで実行されているJavaScriptによって変更できないため、悪意のあるサイトはスプーフィングできません。