の同一生成元制限について、私にはわからないことがあると思いますXMLHttpRequest。
Javascriptコードがhttpリクエストを別のホストに送信することを禁止する代わりに（合法的な使用には本当に迷惑なことです）、リクエストを許可するだけで、その場合はCookieを送信または受け入れない方がよいでしょうか？
文字通りインターネット上の他のすべての人が取得できるものを取得するために特定のスクリプトを禁止することは、一見すると非常に奇妙な選択のように思えます...
私は何が欠けていますか？
Javascriptコードがhttpリクエストを別のホストに送信することを禁止する代わりに（合法的な使用には本当に迷惑なことです）、リクエストを許可するだけで、その場合はCookieを送信または受け入れない方がよいでしょうか？
これが、クロスオリジンリソースシェアリング（CORS）で指定されているものです。
ユーザーのクレデンシャルを使用してクロスオリジンリクエストを行う場合は、アプリケーションが常に注意を払う必要があります。そのようなリクエストを処理するサーバーは、Originヘッダーを含むクレデンシャルの使用に注意を払う必要があります。
- リクエストに取得以外の重要性がある場合、およびクレデンシャルとしてOriginヘッダーに依存する場合、サーバーは、リクエストの承認と、応答内のそのリソースの表現へのアクセスの承認を区別するように注意する必要があります。
..。
クレデンシャルフラグを省略
リクエストでユーザーの資格情報を除外するタイミングと、応答でCookieを無視するタイミングを設定します。
文字通りインターネット上の他の誰もが得ることができる何かを得るために特定のスクリプトを禁止することは、一見すると非常に奇妙な選択のように思えます...
私は何が欠けていますか？
人々が深刻なJavaScriptの重いアプリケーションを書きたいと思うだろうと気付くのに、Web標準機関はしばらく時間がかかりました。Gmailはそれをすべて変えましたが、W3Cのような標準化団体は機能の穴を埋めるのにしばらく時間がかかります。
あなたが提案していることは、最初はユーザーデータが悪用されるのを防ぐことですが、それでもコードが他の潜在的に悪意のあるドメインから実行される可能性があり、リクエストで暗黙的に送信されることなくそのCookieデータを読み取って送信する可能性があります。現在の状況は、セキュリティと柔軟性の間の最良の妥協点だったと思います。