クロスドメインポリシーの回避について少し読んだことがあり、2つの方法が有効であることに気づきましたが、クロスドメインの制限がまったくない場合よりもCORSの方が安全であるかどうかを理解するのに苦労しています。
私が理解しているように、クロスドメイン制限が設定されたのは、理論的には、ユーザーが表示しているページに悪意のあるスクリプトが挿入され、関連付けられていない（つまり同じドメインではない）サーバーにデータが送信される可能性があるためです。ユーザーが具体的にロードしたサイトへ。
CORS機能を使用すると、クロスドメインリクエストを承認できるのは悪意のあるサーバー自体であるため、悪意のあるユーザーがこれを回避できるようです。したがって、悪意のあるスクリプトが、Access-Control-Allow-Origin: *設定された悪意のあるサーバーに詳細を送信することを決定した場合、そのデータを受信できるようになります。
私はここで何かを誤解していると確信しています、誰かが明確にすることができますか？
@dystroyにはポイントがあると思いますが、私が探していたもののすべてではありません。この答えも役に立ちました。https://stackoverflow.com/a/4851237/830431
私は今、それがデータ送信の防止とは関係がなく、不正行為の防止と関係があることを理解しています。
例：ログインしているサイト（ソーシャルネットワークや銀行など）では、ブラウザで信頼できるセッションが開いている可能性があります。その後、危険なサイトにアクセスすると、ログインしているサイトを使用してクロスサイトスクリプティング攻撃を実行できなくなります（スパムステータスの更新の投稿、個人情報の取得、アカウントからの送金など）。クロスドメイン制限ポリシー。クロスサイトスクリプティング攻撃を実行できる唯一の方法は、ブラウザでクロスサイト制限が有効になっていない場合、またはソーシャルネットワークまたは銀行が信頼できないドメインからのリクエストを含めるためにCORSを実装した場合です。
サイト（銀行やソーシャルネットワークなど）がCORSを実装することを決定した場合、不正なアクションや不正なデータが取得されないようにする必要がありますが、ニュースWebサイトのコンテンツAPIやyahooパイプのようなものは失うものがありません*でCORSを有効にする
「*」よりも正確な原点フィルターを設定できます。
特定のページを開いて別のページに含めることにした場合、それは結果を処理することを意味します。
しかし、主な問題は、サーバーが奇妙なデータを受信する可能性があるということではありません。それは新しいことではありません。サーバーが受信するすべてのものが疑わしいものです。保護は主に、ソースの異常な構成（たとえば、エングロブされたデータを読み取ることができるエングロビン）によって悪用されないユーザーを対象としています。したがって、ページのすべてのオリジンを許可する場合は、ユーザーとのみ共有するデータを内部に入れないでください。