なぜSimple Requestが、このような基準なのか

言い換えるとPreflight Requestはなぜ必要なのか？と同じ

SOPとCORSの歴史的経緯を知らないと理解しづらい

結論

SOPが適用されないものに相当するものがSimple Requestになっている

もっと雑に言えば、「 <form> で送信できるもの」がSimple Requestの基準になっている

時代の流れとしては、

SOPがない→SOPが入る→CORSが入る

という順序を踏んでいる

ここで、SOPが追加された直後のことを考えると

SOPが適用されないものは、SOPの導入に関わらずセキュリティのリスクが存在することになる

例えば、formの送信はSOPが適用されない

ということは、formの送信に関しては、server側でセキュリティ対策が施されているべきである

つまりSOPの有無に関わらず、simple requestの脆弱性対策はserver側で為されているはずであるという前提が生まれる

また、SOPが入ったということは、

そもそもcross-originからPUTやDELETEが飛んでくることはない、となる

だから、ここに関してセキュリティ対策をしなくても安全である

この状態で、CORSが追加される

すると、POSTだけでなく、PUTやDELETEもcross originから飛んできうることになる

POSTなどに対しては、既にセキュリティ対策が為されているが、

PUTやDELETEに対しては対策されていない

つまり、ここで線引きが必要になる

もし、この状況下で(preflight requestのない)CORSが追加されると、

Cross OriginからPUTやDELETEが飛んできて、CSRF攻撃を受けてしまう

responseは関係なく、requestでCSRF攻撃は完了できる

これは非常にまずく、server側が新たに対策を実装する必要が出てくる

しかし、W3Cの新規の仕様策定時に、追加のセキュリティ保護の実装が必要になってはいけないので、追加の対策なしで安全にする必要がある

そこで、serverに送る前に「server側は許可してくれますか？」を確認するためにPreflight Requestを送ることにした

全部Preflight Request必須にすれば良くない？とも考えられる

ただし、そうするとPreflight Request分のRTTが1回分増える

不要なRTTは避けたいし、そもそもセキュリティ対策されているはず(前提)

だから、含めなかったのかな

参考