Allow アクションの Gateway HTTP ポリシーは、一致したリクエストが宛先に到達する前にヘッダーを変更できます。動的な値を追加して、ユーザー ID、送信元 IP、その他の入力を上流サービスへ転送するヘッダーを設定したり、SaaS のテナント制御を適用したり、内部ヘッダーを削除したり、ヘッダー内容を上書きしたりできます。
ヘッダー操作には TLS 復号 が必要です。HTTP ヘッダーは、Gateway が復号できるトラフィックでだけ見えるためです。
Gateway の HTTP ポリシーは、3 種類のヘッダー操作に対応します。ヘッダー操作を設定した Allow ポリシーにリクエストが一致すると、Gateway は次の順で適用します。
- Delete - リクエストからヘッダーを削除します。
- Overwrite - リクエスト上のヘッダーを上書きします。名前が一致するヘッダーの値は上書きされます。ヘッダーが存在しない場合は作成されます。
- Add - リクエストにヘッダーを追加します。ヘッダーがすでに存在する場合、追加した値は既存の値に追記されます。
ポリシーあたり最大 20 件のヘッダー操作を設定できます。ヘッダー名は 256 バイトまで、ヘッダー値は 4 KB までです。
ヘッダーの追加は、リクエストに値を追記します。ヘッダーがすでに存在する場合、値は置き換えられず、既存の値と並んで追加されます。
ヘッダーの上書きは、既存の値を上書きします。リクエストにヘッダーがまだない場合は作成されます。クライアントが送った内容に関係なく、特定のヘッダー値を保証したいときに使います。
ヘッダーの削除は、リクエストからそのヘッダーを完全に取り除きます。ヘッダーが存在しない場合、この操作は何もしません。
ヘッダー値には、現在のセッションの ID、デバイス、ネットワークコンテキストを使い、Gateway がリクエスト時に解決する動的変数を含められます。動的変数は @{...} 構文を使い、同じ値の中で静的テキストと混ぜられます。
たとえば、ヘッダー値 user-@{identity.email} は、リクエスト時に user-jdoe@example.com に解決されます。
利用できる動的変数は次のとおりです。
| 変数 | 説明 |
|---|---|
@{identity.email} |
ID プロバイダーから取得したユーザーのメールアドレスです。 |
@{identity.name} |
ID プロバイダーから取得したユーザーの表示名です。 |
@{identity.id} |
ユーザーの Cloudflare ID UUID です。 |
@{identity.groups} |
ユーザーの ID プロバイダーグループ所属です。 |
@{identity.SAML} |
設定されている場合、ID プロバイダーからのユーザーの SAML 属性です。 |
@{identity.OIDC} |
設定されている場合、ID プロバイダーからのユーザーの OIDC クレームです。 |
@{source.ip} |
Gateway から見た、ユーザー接続の送信元 IP アドレスです。 |
@{destination.ip} |
リクエストの宛先 IP アドレスです。 |
@{device.id} |
Cloudflare One Client のデバイス UUID です。 |
@{device.posture} |
デバイスポスチャチェックの結果です(JSON 文字列としてシリアライズされます)。 |
動的変数には、有効な ID セッションが必要です。Gateway が変数を解決できない場合(ユーザーが未認証など)、変数は cf-unresolved や cf-invalid などの警告文字列に置き換わり、HTTP ログに警告が追加されます。
ヘッダー操作付きの HTTP ポリシーを作成するには:
- Cloudflare One ダッシュボード ↗ で、Traffic policies > Firewall policies > HTTP を開きます。
- Add a policy を選択します。
- 変更したいトラフィックに一致する式を作成します。
- Action で Allow を選択します。
- Modify request headers で、ヘッダーの追加または上書きには Add または Overwrite を選び、ヘッダーの削除には Remove を選びます。
- Add と Overwrite の操作では、ヘッダー名と値を入力します。動的変数を使うには、値フィールドに
@{...}構文を入力するか、{}ボタンを選んで利用可能な値の一覧を表示します。Remove の操作では、ヘッダー名だけを入力します。 - ポリシーを保存します。
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 フィールドは次のとおりです。
| フィールド | 型 | 説明 |
|---|---|---|
add_headers |
map<string, array<string>> |
追記するヘッダーです。各キーはヘッダー名、各値は追加する値のリストです。 |
set_headers |
map<string, array<string>> |
上書きするヘッダーです。各キーはヘッダー名、各値は設定する値のリストです。 |
delete_headers |
array<string> |
リクエストから削除するヘッダー名です。 |
1 つのヘッダー値に、静的テキストと動的変数を混ぜられます。例:
{
"add_headers": {
"X-Request-Context": ["user=@{identity.email}, device=@{device.id}, src=@{source.ip}"]
}
}Web トラフィックを分析するためにブラウザーから HAR(HTTP Archive)ファイルを保存しても、Gateway で定義したカスタムヘッダーはそのファイルに現れません。Gateway は、リクエストがブラウザーを離れたあとにヘッダーを挿入するためです。
Gateway がカスタムヘッダーを適用していることを確認するには:
-
カスタムヘッダー付きのポリシーに、HTTP リクエストのテスト用オープンソースサイト HTTPBin ↗ のトラフィックに一致するセレクターを追加します。例:
セレクター 演算子 値 論理演算 アクション 信頼されていない証明書のアクション Application in Google Workspace Or Allow Block Domain in httpbin.org -
デバイスで
httpbin.org/anything↗ を開きます。カスタムヘッダーがヘッダー一覧に表示されます。 -
(任意)ポリシーから HTTPBin の式を削除します。
テナント制御を使うと、ユーザーは企業の SaaS アプリケーションにアクセスでき、同じサービス上の個人アカウントへのアクセスはブロックできます。たとえば、会社の Google Workspace へのアクセスは許可し、個人の Gmail ログインはブロックできます。
Gateway は、一致したリクエストにカスタム HTTP ヘッダーを挿入してテナント制御を実装します。これらのヘッダーは、SaaS アプリケーションに認可されたテナント(組織)を伝えます。ユーザーが個人アカウントで認証しようとすると、SaaS アプリケーションはヘッダーを読み取り、リクエストを拒否します。
Microsoft 365
Microsoft 365 のテナント制御には、2 つのポリシーが必要です。ポリシーの並びは 優先順位 に従ってください。
| 優先度 | セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|---|
| 1 | Domain | is | login.live.com |
Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
Sec-Restrict-Tenant-Access-Policy |
restrict-msa |
| 優先度 | セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|---|
| 2 | Application | in | Microsoft Office365 | Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
Restrict-Access-To-Tenants、Restrict-Access-Context |
組織のドメイン |
詳細は Microsoft Entra ID のドキュメント ↗ を参照してください。
Google Workspace
| セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|
| Application | in | Google Workspace | Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
X-GoogApps-Allowed-Domains |
組織のドメイン |
詳細は Google Workspace のドキュメント ↗ を参照してください。
Slack
| セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|
| Application | in | Slack | Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
X-Slack-Allowed-Workspaces-Requester、X-Slack-Allowed-Workspaces |
組織のワークスペース |
詳細は Slack のドキュメント ↗ を参照してください。
Dropbox
| セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|
| Application | in | Dropbox | Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
X-Dropbox-allowed-Team-Ids |
組織の ID |
詳細は Dropbox のドキュメント ↗ を参照してください。
ChatGPT
| セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|
| Application | in | ChatGPT | Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
Chatgpt-Allowed-Workspace-Id |
組織のワークスペース ID |
詳細は OpenAI のドキュメント ↗ を参照してください。
Claude
| セレクター | 演算子 | 値 | アクション | 信頼されていない証明書のアクション |
|---|---|---|---|---|
| Application | in | Claude | Allow | Block |
| カスタムヘッダー名 | カスタムヘッダー値 |
|---|---|
anthropic-allowed-org-ids |
組織の UUID |
複数の組織からのアクセスを許可するには、スペースなしのカンマ区切り UUID リストを入力します(例: <org-uuid-1>,<org-uuid-2>)。
組織の UUID は claude.ai ↗ の Settings > Account > Organization ID で確認できます。
詳細は Claude のドキュメント ↗ を参照してください。
動的なヘッダー値を使い、上流アプリケーションが Cloudflare Access と直接連携しなくても、ユーザー ID 情報を転送できます。
| ヘッダー名 | ヘッダー値 |
|---|---|
X-User-Email |
@{identity.email} |
X-User-Name |
@{identity.name} |
X-User-Groups |
@{identity.groups} |
X-Source-IP |
@{source.ip} |
上流アプリケーションはこれらのヘッダーを読み取り、ユーザーを識別したり、認可ロジックを適用したり、監査ログに記録したりできます。
クライアントが内部ヘッダーを偽装するのを防ぐには、リクエストを転送する前に 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 通過させるときに便利です。
-
WAF の背後にある内部ドメイン向けに、カスタムヘッダー付きの Allow ポリシーを作成します。
セレクター 演算子 値 アクション Domain in internalapp.comAllow カスタムヘッダー名 カスタムヘッダー値 X-Example-Headerexample-value -
Cloudflare WAF で、同じ HTTP ヘッダーを必須にする カスタムルールを作成 します。
Browser Isolation がカスタムヘッダーを送るよう設定できます。隔離した SaaS アプリケーションのテナント制御や、隔離した Web サイトへの任意のカスタムリクエストヘッダー送信に使えます。
Browser Isolation でカスタムヘッダーを使うには、同じドメインまたはアプリケーショングループを対象とする 2 つの HTTP ポリシーを作成します。たとえば、HTTP リクエストのテスト用オープンソースサイト HTTPBin ↗ 向けのポリシーを作成できます。
-
httpbin.org向けの Isolate ポリシーを作成します。セレクター 演算子 値 アクション Domain in httpbin.orgIsolate -
カスタムヘッダー付きで、
httpbin.org向けの Allow ポリシーを作成します。セレクター 演算子 値 アクション Domain in httpbin.orgAllow カスタムヘッダー名 カスタムヘッダー値 Example-Headerexample-value -
httpbin.org/anything↗ を開きます。Cloudflare は隔離ブラウザーでサイトを描画します。カスタムヘッダーがヘッダー一覧に表示されます。