クロスオリジンリソース共有とは、ウェブページが別のドメイン（ウィキペディア）。
ここ数日、CORS をいじっていましたが、すべてがどのように機能するかをかなりよく理解できたと思います。
したがって、私の質問は CORS / プリフライトの仕組みについてではなく、新しいリクエスト タイプとしてプリフライトを考案した理由についてです。実際のリクエスト (RR) が受け入れられるかどうかを確認するためだけに、サーバー A がサーバー B にプリフライト (PR) を送信する必要がある理由がわかりません。事前の PR がなくても、B が RR を受け入れたり拒否したりすることは確かに可能です。
かなり検索してみたところこの作品情報の詳しくはこちら（7.1.5）：
この仕様が存在する前に特定のユーザー エージェントから発信できなかったクロスオリジン リクエストからリソースを保護するために、リソースがこの仕様を認識していることを確認するためのプリフライト リクエストが行われます。
これは今までで最も理解しにくい文章だと思います。私の解釈（「最善の推測」と呼ぶべきでしょう）は、仕様を認識していないサーバー C からのリクエストからサーバー B を保護することについてであるということです。
誰か、PR + RR が RR 単独よりもうまく解決できるシナリオを説明したり、問題を示してくれたりしませんか?
ベストアンサー1
プリフライト リクエストの目的についてしばらく混乱していましたが、今は理解できたと思います。
重要な洞察は、プリフライト リクエストはセキュリティの問題ではないということです。むしろ、ルールを変更しないためのものです。
プリフライト リクエストはセキュリティとは何の関係もありませんし、CORS を意識して現在開発されているアプリケーションにも何の影響もありません。むしろ、プリフライト メカニズムは CORS を意識せずに開発されたサーバーにメリットをもたらし、クライアントとサーバーの間で両者が CORS を認識しているかどうかの健全性チェックとして機能します。CORS の開発者は、たとえばクロスドメイン DELETE リクエストなど、決して受信しないという前提に依存しているサーバーが世の中に十分あると感じ、双方がオプトインできるようにプリフライト メカニズムを考案しました。彼らは、クロスドメイン呼び出しを単純に有効にする代替策では、既存のアプリケーションの多くに支障をきたすだろうと感じました。
ここでは 3 つのシナリオがあります。
古いサーバー、もはや開発されていない、CORS 以前に開発されたサーバー。これらのサーバーは、たとえばクロスドメイン DELETE リクエストを受信することはないと想定している可能性があります。このシナリオは、プリフライト メカニズムの主な受益者です。確かに、これらのサービスは悪意のあるユーザー エージェントまたは非準拠のユーザー エージェントによってすでに悪用されている可能性があります (CORS はこれを変更するものではありません)。しかし、CORS の世界では、プリフライト メカニズムは追加の「健全性チェック」を提供するため、Web の基本的なルールが変更されたためにクライアントとサーバーが破損することはありません。
まだ開発中のサーバーですが、古いコードが多く含まれており、クロスドメインの世界で正しく動作することを確認するために古いコードをすべて監査することは現実的ではない/望ましくないサーバー。このシナリオでは、サーバーが段階的に CORS にオプトインできます。たとえば、「この特定のヘッダーを許可します」、「この特定の HTTP 動詞を許可します」、「Cookie/認証情報の送信を許可します」などです。このシナリオは、プリフライト メカニズムの恩恵を受けています。
CORS を意識して作成された新しいサーバー。標準的なセキュリティ プラクティスによれば、サーバーは、受信リクエストに対してリソースを保護する必要があります。サーバーは、クライアントが悪意のある行為を行わないとは信じられません。このシナリオでは、プリフライト メカニズムのメリットはありません。プリフライト メカニズムは、リソースを適切に保護しているサーバーにセキュリティを追加しません。