はじめに
『なんだろう？』と思ったものが『あ〜！』ってなったので記事に投稿しました！
ちなみに色々説明し最後にも説明しますが、
『Sec-Fetch-User』はユーザーがちゃんと意図して表示したってことの証明としてつけてくれるもの！です！
これ以上の情報はいらない場合以降は読まなくても問題ないの認識です！
あとリンクは必要なところに記載しているのでよろしくお願いします！
あとこれは基本的なサイト作成で気にしないといけないものかについては『No』の認識です！
サービスで『絶対これは設定しておきたいとか認識していたいもの』『あればみるか〜』みたいなものあると思うのですが、
このヘッダーは『あればみるか〜』ぐらいのものの認識です！(◍•ᴗ•◍) 設定されていない(対応していない)ブラウザもありますし。
こんなことしたい！っと思ったときに頭の片隅にあると案外使える時があるかもぐらいの認識です！
今から話すことを大雑把に表にまとめてみました！
| 項目 | 説明 |
|---|---|
| Sec-Fetch-Dest | リクエストされたものは何か？HTMLで書かれたテキストか？画像か？音楽か的なものを表すもの |
| Sec-Fetch-Mode | 表示させたいコンテンツが何かと、それは今表示しているサイトのドメインとどんな関係かを表すもののイメージ |
| Sec-Fetch-Site | 『前に表示していたサイト』と『今表示しているサイト』 のドメインの関係を表すもの |
| Sec-Fetch-User | ユーザーが動作して表示したものにつく。なので表示した中で呼んでいるscriptとかiframeで呼ばれたものにはつかないのイメージ。 |
まずは何?
以下画像の『リクエストヘッダーの項目』がなんだろう？ってなった。
特に『Sec-Fetch-User』のところ。
ちなみに以下カテゴリはフェッチメタデータリクエストヘッダーというものらしく、以下引用を参考にするとサーバーに自分の情報を追加で教えるよ！みたいなものらしいです！ちなみにJavaScriptから簡単に変更することもできないのでサーバーさんも『お！なるほどこのリクエストは大丈夫そうだ！ってなる感じですかね！』
イメージとしては、
ドアをいつもノックしているだけが、
ドアをいつものノックに加えて『私だよ〜〜』みたいに声も出すイメージ。
そうすればノックされた側は、『あ、クマじゃないかも！人間かも！』って少しは判断材料になるじゃないですか！
そんな感じなのかなって！(逆に例がわかりにくくなっていたらごめんなさい！)
れらのヘッダー名には Sec- の接頭辞が付いており、禁止ヘッダー名であるため、 JavaScript からヘッダーを変更することはできません。
フェッチメタデータリクエストヘッダーは、リクエストがどこから来たのかという追加情報をサーバーに提供し、悪意のあるリクエストを無視できるようになります。
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
で何だったの？の前にちょっと前提知識を
そもそもヘッダーには『リクエストヘッダー』と『レスポンスヘッダー』なるものがあるのですが、
HTTPリクエストヘッダとはリンクに書かれているように、
ブラウザさんが自分の情報を私これなんでこれにちなんだ情報くれってやつの方です！。
例えば、
今私スマホで見ているので、スマホサイト用の画面にしてよこせよこのやろ〜〜的なやつです。
で何だったの？
上記で『リクエストヘッダー』について理解するとある程度この4項目についてなんとなくしっくりするかと思います。
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
上記の『document』だと『document』いわばHTMLで書かれたテキストよこせーみたいな感じです。
ちなみに画像やフォントの時はどうなの？って見たら自分が見ている感じは基本何もついてなかったです。なので今のところ『document』ぐらいが多いのかなのイメージです。ちなみに画像を単独表示(画像リンクコピーブラウザ)表示は『document』となってます。これは画像をブラウザで表示されるようHTMLが作成されているからの認識です。色々言いましたが基本的には『document』はちゃんとつけてくれてるぐらいの認識です。今後クロムのバージョンが上がるとここら辺詳細につけてくれるようになっていくのでしょうか？(◍•ᴗ•◍)
こちらですが付けられるのもの以下ですが、
自分でサイトとかで確認すると『navigate』が多いイメージ。
理由としては、以下引用を参考にするとユーザーが意識して呼び出しているものに『navigate』がつき、それ以外の画像の読み込みや勝手に読み込まれるもの時は『cors』、『no-cors』、『same-origin』のいずれかがつくイメージです。『websocket』は無視します。きっと後者の3つがつく予測です。
ユーザーから発信された要求と、画像やその他のリソースをロードする要求を区別
ちなみに『cors』、『no-cors』、『same-origin』ですが、
・『cors』はクロスサイト(ドメインが表示しているものとは違うサイト)
・『no-cors』は『cors』の逆かと思いきや、単純なリクエストにカテゴリされてる以外のものは受け付けない的なものらしいです。この記事とリンク先は違いますが単純なリクエストのことを言っている認識です。(『単純リクエストは、以下のすべての条件を満たすものです。』の箇所に記載されているもの)
・『same-origin』が『cors』の逆のイメージクロスサイトのものは拒否みたいな認識です。
Sec-Fetch-Mode: cors
Sec-Fetch-Mode: navigate
Sec-Fetch-Mode: no-cors
Sec-Fetch-Mode: same-origin
Sec-Fetch-Mode: websocket
これ以下のイメージ二つみてもらうとわかりやすいかと思うのですが、遷移前と今の表示ページの関係みたいなものが記載されるようです。
同じサイトから来たなら許可しよう許可しないようにしようかと思うときにはこの指標みるもいいかもですね。
ただ対応していないブラウザもあるのでそこらへんそうするか決める的なことは必要になるかもです。
クロムの検索から自分サイトのリンククリックの時
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Sec-Fetch-User: ?1
自分のサイトから自分のサイトを表示の時
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
やっと来ました！本命です！
これの書き方は、
Sec-Fetch-User: ?1
のみで、
これは、
『ユーザーがちゃんと動作して表示しているよ！』 ってときに使われるようです！
なのでiframeで勝手に読み込まれている的なものには上記つかないの認識です。
なるほどです！
Sec-Fetch-Userって結局何のためにつけるの？
ここは憶測になるのですが、
サーバー側がこれをみて、
あ！このページユーザーが意図して表示している感じではない拒否しちゃおうとか。
この情報は出さないでおくかの判断材料ぐらいかなと。
まとめ。
・Sec-Fetch-Userはリクエストヘッダー(カテゴリ的にはフェッチメタデータリクエストヘッダー)の1つ。
・フェッチメタデータリクエストヘッダーはあくまで少し追加情報あげるねのやつ
・ブラウザで対応しているものしていないものそれぐらい対応されていないとかあるかと思うのであればみる的な処理が欲しい認識。
・『Sec-Fetch-User』はユーザーがちゃんと意図して表示したってことの証明としてつけてくれるもの！