ある日UIを作る時に、ヘッダーが正しいのかをチェックするため、developer toolを見たら、ちょっと怪しいヘッダーを見つけました。
Set-Fetch-Mode？何これ？って思う方がいるかもれませんが、一緒に調べてみましょう。
ちょっと変だなと思って、何か誤ってヘッダーを入れたのか？と思いましたが、あまり記憶にありませんでした。
自分のコードは結構シンプルなので、多分これはブラウザから入れたヘッダーということを考えました。
ググってみて、実はこれはFetch Metadata Request Headersという新しい仕様でした。今 Chrome だけこのヘッダーを入れる、他のブラウザはまだ入っていないようです。
CORSをもう一回理解しましょう
みんなさんご存知の通りに、ブラウザは怪しい人がブラウザーからデータを奪わないように、いくつかのポリシーがあります。例えば別のドメインのAPIを呼ぶ際、Access-Control-Allow-Originを正しく設定しないといけないことや、Preflight しないといけないません。詳しくはMDNに書いてあるので、詳細を知りたい人は見てみてください。
それでもいくつの欠点があります。<img>タグは別のドメインにフェッチすることができ、もしsrcから怪しいクエストをしたらデータを奪うことが不可能ではありません。もちろん、サーバー側からちゃんとしたら、これらの攻撃も簡単に防げるでしょう。
もしブラウザからリクエストを送るときに、どこから来たという情報をmeta dataヘッダーに入れたら、サーバー側も判断することができます。
このための仕様が fetch-metadata-request です。
標準仕様
今四つのヘッダーが仕様にあります
1. Sec-Fetch-Dest
どこからこのリクエストきましたっていうヘッダーです。可能な値は audio, document, font, image, object, serviceworkerなど。
このヘッダーさえあれば、サーバーはヘッダーによって、合法かどうかは判断できます。
もしこのリクエストがイメージタグからきた場合でもrouteは/api/my/profile/remove だったら、おそらく hacker と思って良い。エラーコードを返すのが良いでしょう。
2. Sec-Fetch-Mode
このリクエストもモードは何でしょうか？っというヘッダーですが、cors, navigate, nested-navigated, no-corsなどあります。
fetch のmodeオプションと似ています。
3. Sec-Fetch-Site
リクエストは同じドメインなのか、crossドメインなのかを判断できる
4. Sec-Fetch-User
このヘッダーはbooleanで、リクエストが navigation requestに限り、ユーザーがスクリーンから操作があったらtrueになる。
ヘッダーを削除できるのか？
もし仕様になったら、forbidden headersになり、削除することができないと思われます。ブラウからコードを利用してヘッダーの値を変えることはできないので、サーバー側がこのヘッダーの値を信じて良いでしょう。
結論
古い環境で同じことをやりたい場合、自分でヘッダーの定義を制御して、偽造することもおかしくはありません。
仕様は、変えることが難しく 、同じ仕様があるため、サーバー側も実装しやすいです。これからアプリケーションの開発もより安全になるでしょう。