Gateway で HTTP リクエストヘッダーを変更する

Allow アクションの Gateway HTTP ポリシーは、一致したリクエストが宛先に到達する前にヘッダーを変更できます。動的な値を追加して、ユーザー ID、送信元 IP、その他の入力を上流サービスへ転送するヘッダーを設定したり、SaaS のテナント制御を適用したり、内部ヘッダーを削除したり、ヘッダー内容を上書きしたりできます。

ヘッダー操作には TLS 復号 が必要です。HTTP ヘッダーは、Gateway が復号できるトラフィックでだけ見えるためです。

Gateway の HTTP ポリシーは、3 種類のヘッダー操作に対応します。ヘッダー操作を設定した Allow ポリシーにリクエストが一致すると、Gateway は次の順で適用します。

1. Delete - リクエストからヘッダーを削除します。
2. Overwrite - リクエスト上のヘッダーを上書きします。名前が一致するヘッダーの値は上書きされます。ヘッダーが存在しない場合は作成されます。
3. Add - リクエストにヘッダーを追加します。ヘッダーがすでに存在する場合、追加した値は既存の値に追記されます。

ポリシーあたり最大 20 件のヘッダー操作を設定できます。ヘッダー名は 256 バイトまで、ヘッダー値は 4 KB までです。

ヘッダーの追加は、リクエストに値を追記します。ヘッダーがすでに存在する場合、値は置き換えられず、既存の値と並んで追加されます。

ヘッダーの上書きは、既存の値を上書きします。リクエストにヘッダーがまだない場合は作成されます。クライアントが送った内容に関係なく、特定のヘッダー値を保証したいときに使います。

ヘッダーの削除は、リクエストからそのヘッダーを完全に取り除きます。ヘッダーが存在しない場合、この操作は何もしません。

ヘッダー値には、現在のセッションの ID、デバイス、ネットワークコンテキストを使い、Gateway がリクエスト時に解決する動的変数を含められます。動的変数は @{...} 構文を使い、同じ値の中で静的テキストと混ぜられます。

たとえば、ヘッダー値 user-@{identity.email} は、リクエスト時に [email protected] に解決されます。

利用できる動的変数は次のとおりです。

動的変数には、有効な ID セッションが必要です。Gateway が変数を解決できない場合（ユーザーが未認証など）、変数は cf-unresolved や cf-invalid などの警告文字列に置き換わり、HTTP ログに警告が追加されます。

ヘッダー操作付きの HTTP ポリシーを作成するには:

1. Cloudflare One ダッシュボード ↗ で、Traffic policies > Firewall policies > HTTP を開きます。
2. Add a policy を選択します。
3. 変更したいトラフィックに一致する式を作成します。
4. Action で Allow を選択します。
5. Modify request headers で、ヘッダーの追加または上書きには Add または Overwrite を選び、ヘッダーの削除には Remove を選びます。
6. Add と Overwrite の操作では、ヘッダー名と値を入力します。動的変数を使うには、値フィールドに @{...} 構文を入力するか、{} ボタンを選んで利用可能な値の一覧を表示します。Remove の操作では、ヘッダー名だけを入力します。
7. ポリシーを保存します。

API でヘッダー操作付きの HTTP ポリシーを作成するには、rule_settings オブジェクトに add_headers、set_headers、delete_headers を含めます。

curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \
--header "Authorization: Bearer {api_token}" \
--header "Content-Type: application/json" \
--data '{
  "name": "Forward identity headers",
  "action": "allow",
  "enabled": true,
  "filters": ["http"],
  "traffic": "any(http.request.domains[*] in {\"app.example.com\"})",
  "rule_settings": {
    "add_headers": {
      "X-User-Email": ["@{identity.email}"],
      "X-User-Groups": ["@{identity.groups}"]
    },
    "set_headers": {
      "X-Forwarded-User": ["@{identity.email}"]
    },
    "delete_headers": ["X-Debug-Token", "X-Internal-Only"]
  }
}'

ヘッダー操作に使う rule_settings フィールドは次のとおりです。

1 つのヘッダー値に、静的テキストと動的変数を混ぜられます。例:

{
  "add_headers": {
    "X-Request-Context": ["user=@{identity.email}, device=@{device.id}, src=@{source.ip}"]
  }
}

Web トラフィックを分析するためにブラウザーから HAR（HTTP Archive）ファイルを保存しても、Gateway で定義したカスタムヘッダーはそのファイルに現れません。Gateway は、リクエストがブラウザーを離れたあとにヘッダーを挿入するためです。

Gateway がカスタムヘッダーを適用していることを確認するには:

1. カスタムヘッダー付きのポリシーに、HTTP リクエストのテスト用オープンソースサイト HTTPBin ↗ のトラフィックに一致するセレクターを追加します。例:

   セレクター	演算子	値	論理演算	アクション	信頼されていない証明書のアクション
   Application	in	Google Workspace	Or	Allow	Block
   Domain	in	httpbin.org

2. デバイスで httpbin.org/anything ↗ を開きます。カスタムヘッダーがヘッダー一覧に表示されます。

3. （任意）ポリシーから HTTPBin の式を削除します。

テナント制御を使うと、ユーザーは企業の SaaS アプリケーションにアクセスでき、同じサービス上の個人アカウントへのアクセスはブロックできます。たとえば、会社の Google Workspace へのアクセスは許可し、個人の Gmail ログインはブロックできます。

Gateway は、一致したリクエストにカスタム HTTP ヘッダーを挿入してテナント制御を実装します。これらのヘッダーは、SaaS アプリケーションに認可されたテナント（組織）を伝えます。ユーザーが個人アカウントで認証しようとすると、SaaS アプリケーションはヘッダーを読み取り、リクエストを拒否します。

動的なヘッダー値を使い、上流アプリケーションが Cloudflare Access と直接連携しなくても、ユーザー ID 情報を転送できます。

上流アプリケーションはこれらのヘッダーを読み取り、ユーザーを識別したり、認可ロジックを適用したり、監査ログに記録したりできます。

クライアントが内部ヘッダーを偽装するのを防ぐには、リクエストを転送する前に delete 操作でヘッダーを削除し、add または set 操作で検証済みの値を再挿入します。

curl https://api.cloudflare.com/client/v4/accounts/{account_id}/gateway/rules \
--header "Authorization: Bearer {api_token}" \
--header "Content-Type: application/json" \
--data '{
  "name": "Replace internal headers",
  "action": "allow",
  "enabled": true,
  "filters": ["http"],
  "traffic": "any(http.request.domains[*] in {\"internal.example.com\"})",
  "rule_settings": {
    "delete_headers": ["X-Internal-User"],
    "set_headers": {
      "X-Internal-User": ["@{identity.email}"]
    }
  }
}'

HTTP ポリシーにカスタムヘッダーを含め、Cloudflare WAF を通過するユーザーを許可できます。Cloudflare One Client のユーザーだけを WAF 通過させるときに便利です。

1. WAF の背後にある内部ドメイン向けに、カスタムヘッダー付きの Allow ポリシーを作成します。

   セレクター	演算子	値	アクション
   Domain	in	internalapp.com	Allow

   カスタムヘッダー名	カスタムヘッダー値
   X-Example-Header	example-value

2. Cloudflare WAF で、同じ HTTP ヘッダーを必須にする カスタムルールを作成 します。

Browser Isolation がカスタムヘッダーを送るよう設定できます。隔離した SaaS アプリケーションのテナント制御や、隔離した Web サイトへの任意のカスタムリクエストヘッダー送信に使えます。

Browser Isolation でカスタムヘッダーを使うには、同じドメインまたはアプリケーショングループを対象とする 2 つの HTTP ポリシーを作成します。たとえば、HTTP リクエストのテスト用オープンソースサイト HTTPBin ↗ 向けのポリシーを作成できます。

1. httpbin.org 向けの Isolate ポリシーを作成します。

   セレクター	演算子	値	アクション
   Domain	in	httpbin.org	Isolate

2. カスタムヘッダー付きで、httpbin.org 向けの Allow ポリシーを作成します。

   セレクター	演算子	値	アクション
   Domain	in	httpbin.org	Allow

   カスタムヘッダー名	カスタムヘッダー値
   Example-Header	example-value

3. httpbin.org/anything ↗ を開きます。Cloudflare は隔離ブラウザーでサイトを描画します。カスタムヘッダーがヘッダー一覧に表示されます。