CORS（Cross-Origin Resource Sharing）について読んだ後、それがどのようにセキュリティを向上させるのか理解できません。正しいORIGINヘッダーが送信された場合、クロスドメインAJAX通信が許可されます。例として、私が送る場合
サーバーは、このドメインがホワイトリストに含まれているかどうかを確認し、含まれている場合はヘッダーを確認します。
Access-Control-Allow-Origin：[ここで受信したURL]
応答と一緒に返送されます（これは単純なケースであり、事前に戦われた要求もありますが、質問は同じです）。
これは本当に安全ですか？誰かが情報を受け取りたい場合、ORIGINヘッダーを偽造することは本当に簡単な作業のように思えます。また、標準では、ポリシーはブラウザに適用され、Access-Control-Allow-Originが正しくない場合は応答をブロックするとされています。明らかに、誰かがその情報を取得しようとしている場合、彼はそれをブロックするために標準のブラウザを使用しません。
回答:
WebブラウザでJavaScriptを使用してOriginヘッダーを偽造することはできません。CORSはそれを防ぐように設計されています。
Webブラウザーの外では、それは問題ではありません。これは、一般に公開されているデータを人々が取得するのを阻止するようには設計されていません。一般の人々がそれを入手することなしにそれを一般に公開することはできません。
それは与えられるように設計されています：
ボブがチャーリーのウェブサイトにアクセスした場合、チャーリーはJSをボブのブラウザに送信できないため、アリスのウェブサイトからデータを取得してチャーリーに送信します。
ボブがアリスのウェブサイトにユーザーアカウントを持っていて、コメントの投稿、データの削除、一般に公開されていないデータの表示などを行うことができる場合、上記の状況はさらに重要になります。保護がないと、チャーリーのJSがボブのブラウザに通知する可能性があるためです。ボブの後ろでそれを行う（そして結果をチャーリーに送る）。
許可されていない人がデータを見るのを防ぎたい場合は、パスワード、SSLクライアント証明書、またはIDベースの認証/承認の他の手段でデータを保護する必要があります。
目的はこれを防ぐことです-
銀行のWebサイトは、WebサイトXのスクリプトが銀行のページにアクセスするために信頼されるべきかどうかをブラウザに通知する方法が必要であるという考えです。
Access-Control-Allow-Origin（で指定された原点ヘッダ指定Originヘッダ）がリソースにアクセスすることを許可されています。通常、同じオリジンを持つリクエストのみがそうすることが許可されます。ここで最も重要な部分は次のとおりです。許可/拒否は、サーバーではなくブラウザによって強制されます。これはAccess-Control-Allow-Origin、サーバー上のリソースやサーバー自体ではなく、ブラウザを保護することを意味します。
@jcoderの答えを追加するだけで、 Originヘッダーのサーバーで要求されたリソースを保護することではありません。攻撃者が実際に適切なツールを使用してこのヘッダーをスプーフィングできるため、そのタスクは他の手段を介してサーバー自体に任されています。
Originヘッダーのポイントは、ユーザーを保護することです。シナリオは次のとおりです。
攻撃者が悪意のあるWebサイトを作成するM
ユーザーのアリスは、実際にCORSをサポートしているサーバーBでCORSを介していくつかのアクションを実行しようとするスクリプトを含むMに接続するようにだまされます。
BのAccess-Control-Allow-OriginヘッダーにはおそらくMが含まれていませんが、なぜそうなるのでしょうか。
重要な点はOrigin、リクエストはアリスのブラウザによって開始されるため、Mにはヘッダーをスプーフィングまたは上書きする手段がないということです。したがって、彼女のブラウザは（正しい）OriginをAccess-Control-Allow-OriginBにないMに設定するため、リクエストは失敗します。
アリスは変更することができます Origin自分でヘッダーを、それは彼女が自分自身を傷つけていることを意味するので、なぜ彼女はそうするのでしょうか？
TL; DR： Originヘッダーは無実のユーザーを保護します。サーバー上のリソースは保護されません。攻撃者が自分のマシンでスプーフィングすることはできますが、攻撃者の制御下にないマシンでスプーフィングすることはできません。
一致するOriginヘッダーは許可されたアクセスを意味しないため、サーバーは引き続きリソースを保護する必要があります。ただし、Origin一致しないヘッダーは、不正アクセスを意味します。
同一生成元ポリシーの目的は、一般的に人々がWebサイトのコンテンツにアクセスするのを阻止することではありません。誰かがそれをしたいのなら、彼らはブラウザさえ必要としません。重要なのは、必要なアクセス権なしに、クライアントスクリプトが別のドメインのコンテンツにアクセスするのを停止することです。同一生成元ポリシーについては、ウィキペディアのエントリを参照してください。
CORSについて読んだ後、それがどのようにセキュリティを向上させるのか理解できません。
CORSはセキュリティを向上させません。CORSは、サーバーが外部ドメインからアクセスする方法をブラウザーに指示するメカニズムを提供し、CORSの前に存在していたブラウザーのセキュリティモデル（つまり同一生成元ポリシー）と一致する方法でそうしようとします。
ただし、同一生成元ポリシーとCORSの範囲は限られています。具体的には、 CORS仕様自体には、リクエストを拒否するメカニズムがありません。ヘッダーを使用して、外部ドメインのページに応答を読み取らせないようにブラウザーに指示できます。また、プリフライトリクエストの場合、外部ドメインからの特定のリクエストを送信しないようにブラウザに要求できます。ただし、CORSは、サーバーが実際のリクエストを拒否する（つまり、実行しない）ための手段を指定していません。
例を見てみましょう。ユーザーはACookieを介してサイトにログインします。ユーザーが悪意のあるサイトをロードMし、POSTを実行するフォームを送信しようとしAます。何が起こるか？CORSの有無にかかわらずM、許可されたドメインの有無にかかわらず、ブラウザはリクエストをに送信しますAユーザーの認証Cookieを使用して、サーバーはPOSTユーザーが開始したかのように悪意のあるユーザーを実行します。
この攻撃は クロスサイトリクエストフォージェリと呼ばれ、CORS自体はそれを軽減するために何もしません。そのため、ユーザーに代わってデータを変更するリクエストを許可する場合、CSRF保護は非常に重要です。
これで、Originヘッダーの使用がCSRF保護の重要な部分になる可能性があります。実際、それをチェックすることは、多面的なCSRF防御に関する現在の推奨事項の一部です。。ただし、Originヘッダーの使用はCORS仕様の範囲外です。
要約すると、CORSは、既存の同一生成元ポリシーセキュリティモデルを他の承認されたドメインに拡張するための便利な仕様です。セキュリティは追加されず、サイトにはCORS以前と同じ種類の防御メカニズムが必要です。
私は答えるのが遅れていますが、ここの投稿が本当に求められている答えを提供しているとは思いません。最大のポイントは、ブラウザーがoriginヘッダー値を書き込んでいるエージェントであることです。邪悪なスクリプトはoriginヘッダー値を書き込むことができません。サーバーがAccess-Control-Allow-Originヘッダーで応答すると、ブラウザーはこのヘッダーにorigin以前に送信された値が含まれていることを確認しようとします。そうでない場合は、エラーがトリガーされ、要求元のスクリプトに値が返されません。この質問に対する他の回答は、邪悪なスクリプトへの回答を拒否したい場合の良いシナリオを示しています。
@danielfも質問に対する良い答えを提供します