より安全なリクエストヘッダー-メタデータの取得リクエストヘッダー

ある日、ウェブページを開発しているとき、リクエストヘッダーの項目が正しいか確認するために開発ツールを開いたところ、いくつかの怪しいヘッダーがリクエストに追加されているのを発見しました。

怪しい点に気づきましたか？よく見ると、Sec-Fetch-* で始まるヘッダーが3つもあることに気づきました。 これは私の注意を引きました。これらのヘッダーは設定していないし、他の関数も適用していないのに、なぜ勝手に追加されているのか、ブラウザが関与しているのではないかと推測しました。

調べてみたところ、これは Fetch Metadata Request Headers という新しい草案であることが分かりました。現在、これらのヘッダーはChromeでのみ追加され、FirefoxやSafariでは追加されません。

再び同一生成元ポリシー（CORS）について

私たちは、ブラウザが悪意のある人物によるデータの盗用を防ぐために、特定のオリジンへのアクセス条件を制限していることを知っています。例えば、クロスオリジンリクエスト時には Access-Control-Allow-Origin を追加する必要があり、またPreflightリクエストも必要です。詳細は私が以前書いた「CORSとCookieの対処法」を参照してください。

それにもかかわらず、いくつかの欠陥があります。例えば、<img/> はクロスオリジンリクエストを送信できてしまうため、悪意のある人物がCORSの制限を回避することが可能です。当然、サーバーが基本的な防御策を講じていれば、大部分の不正なリクエストを防止できます。

リクエストを送信するときに、追加のヘッダー情報（metadata）を付加してリクエストの出所を示せれば、サーバーはそのヘッダーに基づいて適切な応答を行うことができるため、このような草案が生まれました。

ヘッダーの仕様：

現在、草案には主に4つのヘッダーがあります：

1. Sec-Fetch-Dest

このリクエストの目的地を示します。

可能な値には、audio、document、font、image、object、serviceworker などがあります。これにより、サーバーはリクエストの出所が合法かどうかを瞬時に判断できます。例えば、<img> からのリクエストでサーバーに画像を要求していない場合、ほぼ確実にハッカーであるため、エラーを返すことができます。

2. Sec-Fetch-Mode

リクエストのモードを示します。主にcors、navigate、nested-navigate、no-corsなどがあり、リクエストがどのようなモードであるかを判断します。これは fetch の中のmodeに似ています。

また、Set-Fetch-User により、ユーザーが操作（例えばクリックやキーボードなど）を通じてリクエストを発信したかどうかも知ることができます。

3. Sec-Fetch-Site

リクエストの出所が同一生成元かクロスオリジンかを示します。

4. Sec-Fetch-User

このヘッダーの値はブール値で、リクエストが navigation request（リクエストの目的地がdocument）であり、かつユーザーがインタラクションを行った場合（例えばボタンを押す、キーボード操作など）にのみtrueになります。サーバーはこのヘッダーに基づいて、ユーザーがリクエストを発信する方法が合法であるかどうかを判断できます。

例えば、フォームをクリックして送信する際、documentからリクエストが送信され、ユーザーがインタラクションを行ったため（ボタンをクリックして送信）、Set-Fetch-User は ?T になります。

ヘッダーを削除する方法はありますか？

もしこの草案が規範となった場合、ヘッダーを削除することはできない可能性があります。また、手動で設定してヘッダーの値を書き換えることはできません。なぜなら、それは forbidden headers の一つだからです。

結論

以前は、同様のことを実現するためにカスタムヘッダーを使用していましたが、偽造される可能性がありました。また、カスタムヘッダーを追加するにはPreflightのチェックが必要で、手間が増えました。規範に基づく利点は、これらのヘッダーが容易に書き換えられないことであり、統一された標準を提供することです。これらのヘッダーがあれば、バックエンドはリクエストを受け取る際にさらに多くの判断を行い、安全性を高めることができます。