プリフライトの線は、フォームが送れた範囲に引かれている

別オリジンへ要求を送るとき、ブラウザは要求によって、本体の前に OPTIONS を送って宛先の許可を確かめます。これがプリフライトです。すべての要求に付くわけではありません。線の位置を、Fetch Standard §3.3.1 はこう書きます。

For requests that are more involved than what is possible with HTML’s form element, a CORS-preflight request is performed, to ensure request’s current URL supports the CORS protocol.

基準は HTML のフォーム要素でできること です。具体的な条件は2つの定義に分かれています。

A CORS-safelisted method is a method that is GET, HEAD, or POST.

Content-Type については、essence が次の3種でなければ safelisted ではない、と書かれます。

If mimeType’s essence is not "application/x-www-form-urlencoded", "multipart/form-data", or "text/plain", then return false.

§4.1 の主な条件はこの2つの組み合わせで、メソッドが safelisted でないか、safelisted でないヘッダ名が1つでもあればプリフライトを行う、と定めます。値の長さにも上限があり、1つのヘッダ値が128バイトを超えるか、safelisted なヘッダ値の合計が1024バイトを超えると、事前確認の対象になります。

HTML Standard のフォーム送信の節を並べると、線の位置が見えます。enctype 属性のキーワードは3つです。

• The "application/x-www-form-urlencoded" keyword and corresponding state.
• The "multipart/form-data" keyword and corresponding state.
• The "text/plain" keyword and corresponding state.

method 属性は get・post・dialog で、dialog は送信しません。

             Fetch(事前確認なし)                           HTML フォーム
メソッド     GET / HEAD / POST                              get / post
Content-Type urlencoded / multipart/form-data / text/plain  同じ3種(既定は urlencoded)

違うのはメソッドの行の HEAD だけで、フォームからは送れないのに safelisted に入っています。その理由はこの教材では確かめていません。

ここからは教材側の読みです。フォームの範囲に収まる要求は、スクリプトが無くても別サイトのページから送れました。そこにプリフライトを足しても、送られてしまう要求は減りません。事前確認が意味を持つのは、フォームでは作れなかった要求のほうです。

裏返すと、プリフライトは「本人が望んだか」を確かめる仕組みではありません。 確かめるのは宛先が CORS に対応しているかで、フォームの範囲の要求はその確認すら経ずに届きます。