多数のCORSプロキシが実行されている場合、オリジン間のリソース共有のポイントは何ですか？
CORS（クロスオリジンリソースシェアリング）の方向性が本当に好きではありませんでした。クライアントとサーバー間の通信のしくみには誤解があると思います。
一般的な概念は次のとおりです。
User:こんにちはServer、このようなリクエストを送信しています
- サーバーはリクエストをサポートします：
Server:こんにちはユーザー、リクエストへの返信を送信しています。- サーバーはリクエストをサポートしていません、REFERRERは一致しませんなど：
Server:400-不正なリクエスト
しかし、OK、特定の試行で400エラーを想定することで、CORSがサーバーを好んでいるとしましょう。たとえば、ユーザーのプロファイル情報がログオンしているという事実を悪用するなどです。これは確かに良いと思いますが、現在実装されている方法は愚かに見えます：
スクリプトは異なるOriginにリクエストを送信したい...
User:HelloServer、リクエストを送信します。どのようなリクエストを受け入れますか？
- サーバーはCORSを認識しています：
Server:こんにちは、CORSポリシーを送信しています。
ブラウザは送信するか送信しないかを決定します...- サーバーはCORSを認識しません：
Server:404-見つかりません
くそ...画像を取得したかっただけです...
しかし、なぜCORSは単にCookieを削除しないのですか？多くの場合、スクリプトは異なるOriginからJSON、他のスクリプト、または画像を取得することを望みます。その場合、サーバープロキシを確立する必要があります。これら プロキシは非常に人気があります 。
この進歩により、Webアプリケーション（ファイルの保存、ファイルの解析など）のサーバー非依存性が非常に複雑になりました。
それでは、プロキシを介してバイパスできるGETリクエストをブロックするポイントは何ですか？
CORSの焦点は、最終ユーザーのWebをより安全にすることであり、その実装のほとんどは、実際には最新のブラウザーにカプセル化されていると思います。
つまり、リファラーヘッダーを常に送信してバイパスすることはできないため、サーバー側のコンテンツを保護または到達不能にするだけでは設計されていません。これは明らかに、XSS攻撃を心配することなくWebを楽しく閲覧したいだけの「無意識の」Webユーザーには当てはまりません。