すべてのドメインをCORSに追加することのセキュリティへの影響（Access-Control-Allow-Origin：*）
すべてのドメインを [〜＃〜] cors [〜＃〜] に追加する代わりに、ドメインのセットのみを追加する必要があると言われています。ただし、ドメインのセットを追加するのは簡単ではない場合があります。例えば。 APIを公開する場合、そのAPIを呼び出したいドメインごとに、許可されたドメインのリストにそのドメインを追加するために連絡する必要があります。
セキュリティへの影響と作業量を減らすことを意識してトレードオフを決定したいと思います。
私が目にする唯一のセキュリティ問題は、 DoS攻撃 および [〜＃〜] csrf [〜＃〜] 攻撃です。 CSRF攻撃は、IMG要素とFORM要素ですでに達成できます。 CORSに関連するDoS攻撃は、リファラーヘッダーで要求をブロックすることで克服できます。
セキュリティへの影響がありませんか？
===編集===
Access-Control-Allow-Credentialsヘッダーが設定されていません- ドメイン「CORSアクセス」の特定のリストを追加する方法を知っているため、すべてのドメイン「CORSアクセス」を追加することのセキュリティへの影響のみに関心があります。
csauveの場合を除き、元の質問に答える回答はありません。
私の質問に答えるために; Access-Control-Allow-Credentialsが設定されていない場合、セキュリティ上の問題はありません。
（これは、なぜAccess-Control-Allow-Credentialsは設定されていませんか？）
クロスサイトリクエストフォージェリ攻撃は、Access-Control-Allow-Originが対処する最大の関心事です。
ライアンはコンテンツの取得に関して確かに正しいです。ただし、リクエストの作成に関しては、ここでさらに説明する必要があります。現在、多くのWebサイトがRESTful Webサービスを提供しており、バックエンドの大幅な変更を伴う可能性のある幅広い機能を公開しています。非常に多くの場合、これらのRESTfulサービスは、XHR（AJAXなど）リクエスト（おそらくフロントエンドとして「 Single Page Application 」）で呼び出されることを意図しています。ユーザーが悪意のあるサードパーティのサイトにアクセスしたときにこれらのサービスへのアクセスを許可するアクティブなセッションを持っている場合、そのサイトはそれらのRESTエンドポイントをバックグラウンドで呼び出し、ユーザーまたはサイト。 RESTサービスの定義方法に応じて、これに対するさまざまな保護方法があります。
シングルページアプリのREST Webサービスの特定のケースでは、バックエンドRESTエンドポイントへのすべてのリクエストがXHRで行われ、非XHRリクエストを拒否するように指示できます。これは、カスタムリクエストヘッダー（jQueryのX-Requested-Withなど）の存在を確認することで指示できます。これらのヘッダーを設定できるのは、XHRタイプのリクエストのみです。フォームおよび埋め込みリソースからの単純なGETおよびPOST要求はできません。最後に、XHRリクエストを指示する理由により、元の質問に戻ります。XHRリクエストにはCORSルールが適用されます。
Access-Control-Allow-Origin: *を許可した場合、どのサイトでもAJAXエンドポイントに対してユーザーに代わってRESTリクエストを行うことができます。 RESTエンドポイントに機密データが含まれる場合、またはデータの永続性が許容される場合、これは許容できないセキュリティ脆弱性です。代わりに、私が説明したようにXHRのみのリクエストを強制し、それらのリクエストを行うことができるオリジンのホワイトリストを定義します。
RESTエンドポイントが機密情報を公開しない場合、またはユーザーによる永続的なデータ変更を許可しない場合、Access-Control-Allow-Origin: *が適切な決定である可能性があることに注意してください。たとえば、Googleマップは公開地図データの読み取り専用ビューを提供します。これらのサービスを呼び出すことを希望するサードパーティのサイトを制限する理由はありません。
古い質問ですが、ここには多くの悪い答えがありますので、私のものを追加する必要があります。
Access-Control-Allow-Credentialsを設定せず、Cookieなしの認証を行う場合（つまり、発信者がBearer Authorizationヘッダーを提供する場合）、発信元をホワイトリストに登録する必要はありません。 OriginをAccess-Control-Allow-Originにエコーバックするだけです。
適切に構成されたREST APIは、任意のOriginから安全に呼び出すことができます。
次のように複数送信できます。
Access-Control-Allow-Origin: http://my.domain.com https://my.domain.com http://my.otherdomain.com
しかし、私はそれに対して助言します。代わりに、許可されたドメインのホワイトリストを保持してください。まあ言ってみれば：
allowed = [ "X", "Y", "A.Z" ];
次に、Xからリクエストを受け取った場合、次のように応答します。
Access-Control-Allow-Origin: X
A.Zからリクエストを受け取った場合、次のように応答します：
Access-Control-Allow-Origin: A.Z
許可されていないドメインからリクエストを受け取った場合は、エラーで応答するか、CORSポリシーを使用しません。
すべてのXHRリクエストはOriginヘッダーを送信するため、それを使用します。また、後続のGET/POST/HEADリクエストではなく、OPTIONSリクエストのCORSポリシーヘッダーのみを送信する必要があります。
主な問題は、すべてのドメインを公開することです。 https://admin.mydomain.comのような安全な管理ドメインを持っているか、まだ立ち上げられていない製品のWebサイトを持っている可能性があります。手元のリクエストに絶対に必要ではないものを含めたくありません。
*は非常に怠zyです。
CORSは、リクエストを行うだけでなく、コンテンツを取り戻すことです。 imgまたはscriptタグを介してリソースを取得すると、誰かのブラウザをだましてCSRFスタイルのリクエストを作成できます。これは正常な動作であり、通常のCSRFトークンで保護できます。
すべてのドメインでCORSを有効にすると、攻撃サイトのjavascriptでリクエストを行い、コンテンツを取得してプライバシーを侵害できるようになりました。
例：
背中がすべてのドメインでCORSを有効にしていると想像してください。今、私はyourimaginarybank.com/balanceにリクエストを行うウェブサイトを作ります
IMGリクエストは何もしません。なぜなら、私のJavaScriptは銀行のWebサイトのそのページのhtmlにあるものを取得できないからです。 CORSが有効になったので、私のサイトのjavascriptは実際に残高のあるHTMLページを取得し、サーバーに保存します。以前のようにGETリクエストを作成できるだけでなく、内部の内容を確認できます。これは大きなセキュリティ問題です。
大きなリストをヘッダーに追加せずに問題を解決するにはどうすればよいですか？各CORS要求は、Originヘッダーを使用して作成されます。最良の解決策はおそらく、Originヘッダーを読み取り、データベースに照会して、Fritzの回答で示唆されているようにホワイトリストに登録されているかどうかを確認することです。