リクエストに対して同じOriginポリシーが賢明なのはなぜですか？
これは と同じ質問ではありません。なぜ同じOriginポリシーがそれほど重要なのですか 。
それはなぜCookieが送信元にのみ送信されるのかを尋ねるだけだと私は理解しています。
私が理解していないのは、ブラウザからリクエストできるリソースに制限がある理由です。なぜ
セキュリティ上の理由から、ブラウザはスクリプト内から開始されたクロスオリジンHTTPリクエストを制限します。たとえば、XMLHttpRequestとFetch APIは、同じオリジンポリシーに従います。
（（ developer.mozilla.org から））
明らかに、Webアプリケーション開発者は、そのようなリクエストをアプリのサーバーに委任することにより、常にこの制限を回避できます。
最初に、XSSがWebアプリに侵入しても、攻撃者が重要なデータを自分に送信できないようになっているのではないかと考えましたが、それでも可能です。 CORSヘッダーは要求されたリソースからのものであり、奇妙なことに、Originサーバーからのものではないためです（コンテンツセキュリティポリシーの場合と同様に、私も理解しています）。
それで、ポイントは何ですか？
問題は、そもそもSOP/CORSの目的について少し誤解しているかもしれないということです。 SOPはデータを別のオリジンに送信することを禁止していません-readingからの応答を防ぐだけです） Originを分離します。
最初は、XSSがWebアプリに侵入しても、攻撃者が重要なデータを自分に送信できないようにするためだと思いました
そして、攻撃者が受信サーバーでいくつかのCORSヘッダーを有効にすることで、自分自身にデータを送信できることを明確にします。ただし、それは必須ではありません。単純なGETおよびPOST要求の場合、ブラウザーは引き続きsend宛先サーバーに要求を送信し、そのサーバーはまったく問題なく通常どおり受信して操作できます。SOPの結果として変更されるのは、ブラウザが呼び出しスクリプトにサーバーからの応答を受け取ります[**下の例外]。
それが本当に重要です。 same-Origin-policyは、Origin Bから明示的に許可されていない限り、Origin AがOrigin Bから何かを読み取ることを拒否することについてすべてです。そのため、CORSヘッダーは、Originサーバーではなく受信サーバーで設定されます。誰かが誤ってevil.comにアクセスした場合、facebook.comが明示的に他のことを述べていない限り、そのページのJavaScriptがfacebook.comからデータを読み取れるようにしたくありません。
もちろん、これの主なユースケースはアクセス資格情報です。リクエストを行うJavaScriptがfacebook.comで実行されている場合でも、ブラウザはfacebook.comからevil.comに送信されるすべてのリクエストにCookieを自動的に添付します。その結果、SOPがクロスドメインの読み取りを防止しなかった場合、JavaScriptが制御しているページにアクセスすると、誰でもFacebookのプロファイルを読み取ることができます。Cookieの送信に対するブラウザの要求特定のドメインへのすべての要求（多くのWebアプリケーションが適切に機能するための要件である）は、SOPおよびCORS制限の背後にある主な推進力です。
認証を使用しないWebサイトの場合、CORSは通常、それほど重要ではなくなります。結局のところ、あなたが言うように、要求はサーバーによって簡単に作成でき、ブラウザで実行されているJavaScriptに応答が中継されます。そのような場合、サイトはすべてのリクエストでAccess-Control-Allow-Origin: *を送信することでCORSを無効にすることもできます。サーバーがそれを行う場合、Access-Control-Allow-Credentials: trueフラグをオンに設定することもできないことに注意してください。ブラウザでは、すべての人にあなたのコンテンツを読み取らせたり、すべてのリクエストにCookieを送信したりすることはできません。
繰り返しますがすべて：SOPは、Origin Aで実行されているjavascriptがOrigin Bから何かを読み取ることを禁止することです。ドメイン/プロトコル/ポートを分離して、自分の物だけを読むことができるようにします、およびWebブラウザーに組み込まれた最も基本的な保護の1つです。
** SOP/CORSは、ブラウザがリクエストを送信することを停止しないと述べました。このルールには例外があります。 「非標準」リクエストの場合、ブラウザは「プリフライト」検証リクエストを送信します。具体的には、「OPTIONS」のリクエストメソッドを使用してエンドポイントにリクエストを送信し、受け入れるリクエストの種類をサーバーに要求します。送信されるリクエストが一致しない場合、ブラウザはそもそもリクエストを送信しません。
追加して編集
明らかに、あなたの主な質問は「しかし、Cookieが含まれていないのに、そもそもなぜ読み取りをブロックするのか？」です。私は元の答えでそれを取得することを目指していましたが、もっと直接的に対処するようにしましょう：
あなたは（この特定のケースでは）間違った視点からセキュリティを見ています。特定の特権へのアクセスを拒否する理由を効果的に探している（つまり、「それができないのはなぜですか？」）。セキュリティの問題に対処するより強力な方法は、反対の方向からです。つまり、全員に必要な最小限の特権を与え、理由がある場合にのみ追加のアクセス権を与える必要があります。 「なぜこれができないのですか」と尋ねる代わりにより良い質問は「なぜこれをさせなければならないのか？」です。
その観点から見ると、SOPのデフォルトポリシーは、明示的に承認されていない限り、すべての読み取り要求をブロックし、基本的には標準のセキュリティです。はい、ユーザーはこのセキュリティ手順を回避できます。サーバー経由でリクエストを行うなどの方法で行います。ただし、セキュリティ手順を回避できるということは悪い考えではありません。車のドアのロックを回避する方法はたくさんありますが、それはつまり、車のロックを停止するだけです。優れたWebセキュリティとは、多層防御です。1つの領域に弱点が見つかった場合でも、システムは安全です。SOP =読み取り制限は、基本的にWebアプリケーションのセキュリティの最初の層にすぎません。