Edge 153のHttpHeaderInjectionとは？HTTPヘッダー注入の設定・検証・漏えい対策

Microsoft Edge 153以降では、Enterprise PolicyのHttpHeaderInjectionを使い、指定したURLパターンに一致するWebリクエストへ任意のHTTPリクエストヘッダーを追加できます。

ただし、安全に運用するには、対象を単なるドメイン名ではなく、HTTPS・完全一致ホスト・必要なパスまで限定することが重要です。また、APIキーやBearerトークンなどの秘密情報は設定せず、導入前に対象外URL、リダイレクト先、サブリソースへの送信有無まで検証する必要があります。(Microsoft Learn)

2026年9月3日時点ではEdge 153 Betaが公開されており、Stable 153は2026年9月10日の週にリリース予定です。Extended Stableでは153が提供対象外となっているため、Extended Stable運用環境では対応する後続バージョンまで利用できない点にも注意してください。(Microsoft Learn)

Edge 153のHttpHeaderInjectionポリシーとは

HttpHeaderInjectionは、管理者が指定したURLに対して、Microsoft EdgeがHTTPリクエストヘッダーを自動追加するポリシーです。

一般的な「HTTPヘッダーインジェクション攻撃」とは異なり、管理者が定義した固定値を、管理対象のEdgeから意図的に送信するための企業向け機能です。

代表的な利用例として、次のようなケースが考えられます。

SaaSや社内Webシステムへ組織IDを通知する
リバースプロキシで接続元の管理区分を判定する
特定テナントへのアクセス制御に必要な識別ヘッダーを付ける
管理対象ブラウザーからのアクセスであることをサーバー側へ伝える
特定環境向けのルーティングや機能切り替えに固定値を使用する

公式ドキュメントでは、テナントアクセス制御のためにX-Tenant-IDのようなカスタムヘッダーを追加する利用例が示されています。ポリシーによって追加された値は、Webページや拡張機能が設定した同名ヘッダーより優先されます。(Microsoft Learn)

なお、HttpHeaderInjection自体はアクセスを許可・拒否する機能ではありません。実際にアクセスを制御するには、受信側のWebサービスやプロキシがヘッダーを確認し、不正な値やヘッダー未付与のリクエストを拒否する必要があります。

対応環境と主な仕様

公式仕様を整理すると、次のようになります。(Microsoft Learn)

項目	仕様
Windows	Microsoft Edge 153以降
macOS	Microsoft Edge 153以降
Android	非対応
iOS	非対応
ポリシー名	`HttpHeaderInjection`
ポリシーの種類	必須ポリシーのみ
推奨ポリシー	非対応
動的ポリシー更新	対応
プロファイル単位	対応
個人用Microsoftアカウントのプロファイル	適用対象外
Windowsのレジストリ値	`REG_SZ`
URLパターン数	全ルール合計で最大500
1ルール内のヘッダー数	最大20
1ヘッダーの上限	8KB

ヘッダー値にはNUL、CR、LFを含められません。無効なヘッダーやURLパターン、上限を超えた設定は無視されます。

設定全体がエラーになるとは限らず、一部だけが無視される可能性があるため、edge://policyに表示されたことだけで正常と判断せず、実際の通信も確認する必要があります。

HttpHeaderInjectionが向いている用途と向いていない用途

導入前に、そもそもブラウザー側でHTTPヘッダーを追加する設計が適切かを判断しておきましょう。

要件	HttpHeaderInjectionの適性
固定の組織IDやテナントIDを送信したい	適している
管理対象Edgeからの通信を識別したい	適している
特定ホストの特定パスだけに固定値を付けたい	適している
ユーザーごとに異なる短期トークンを発行したい	適していない
APIキーやパスワードを安全に保管したい	適していない
Edge以外のブラウザーにも同じ制御を適用したい	適していない
サーバー側で動的に値を生成したい	リバースプロキシなどが適する
ヘッダーがない通信そのものを遮断したい	サーバー側の検証が必要

公式仕様で設定できるのは、ヘッダーのnameと固定のvalueです。ユーザー属性を参照する置換変数や、利用時にトークンを動的発行する仕組みは示されていません。ユーザーごとに異なる値が必要な場合は、認証基盤、リバースプロキシ、SSE、APIゲートウェイなどを使う方が適しています。(Microsoft Learn)

HttpHeaderInjectionの設定形式

設定値は、複数のルールを含むJSON形式で記述します。

各ルールには、次の2つの要素があります。

要素	内容
`patterns`	ヘッダーを追加するURLパターン
`headers`	追加するヘッダーの名前と値

安全性を重視した設定例は次のとおりです。

[
  {
    "patterns": [
      "https://.portal.example.jp/tenant-a/"
    ],
    "headers": [
      {
        "name": "X-Organization-ID",
        "value": "tenant-a"
      }
    ]
  }
]

この例では、次の条件をすべて満たすリクエストだけにヘッダーを追加します。

通信方式がHTTPS
ホスト名がportal.example.jpと完全一致
パスが/tenant-a/で始まる

URLパターンの先頭にあるドットは入力ミスではありません。https://.portal.example.jp/のように、ホスト名の直前へ.を付けることで、サブドメインを含めず完全一致させます。 (Microsoft Learn)

URLパターンはできるだけ狭く指定する

HttpHeaderInjectionで最も注意すべき点は、URLパターンの指定範囲です。

Microsoft EdgeのURLリスト形式では、ドットを付けないホスト名は、そのホストと配下のサブドメインにも一致します。スキームやポートを省略すると、意図していない接続方式にも一致する可能性があります。(Microsoft Learn)

パターン	主な一致範囲	判断
`*`	すべてのホスト	原則として使用しない
`example.jp`	`example.jp`と配下のサブドメイン	広すぎる可能性が高い
`.portal.example.jp`	ホストは完全一致、スキームは限定しない	HTTPにも一致し得る
`https://.portal.example.jp/`	HTTPSかつホスト完全一致	基本形として安全
`https://.portal.example.jp/tenant-a/`	HTTPS、完全一致ホスト、指定パス	より安全
`https://.portal.example.jp:8443/tenant-a/`	非標準ポートまで限定	ポート固定時に有効

たとえば、次の指定は避けた方が安全です。

example.jp

この指定では、次のようなホストにも一致します。

portal.example.jp
cdn.example.jp
test.example.jp
old-system.example.jp

将来追加されたサブドメインや、別部署、委託先、開発環境で管理されているサブドメインにもヘッダーが送信される可能性があります。

対象が1つのWebシステムだけであれば、次のように指定します。

https://.portal.example.jp/

さらに特定の機能だけで必要なら、パスも限定します。

https://.portal.example.jp/managed-access/

URLフィルターではスキームとホスト名の大文字・小文字は区別されません。一方、パスとクエリは大文字・小文字が区別されます。/Managed-Access/と/managed-access/が異なるシステムでは、実際のURL表記を正確に確認してください。(Microsoft Learn)

複数ルールが一致した場合の優先順位

1つのリクエストに複数のルールが一致した場合、異なる名前のヘッダーはすべて適用されます。

同じヘッダー名が複数のルールに含まれている場合は、次の順序で値が決まります。

より具体的なURLパターンのルールが優先される
同じ具体性なら、設定リストの後ろにあるルールが優先される

また、ポリシーで追加するヘッダーは、リクエストにすでに存在する同名ヘッダーや、ユーザーまたは拡張機能による変更より優先されます。(Microsoft Learn)

次の例では、通常はprod、/pilot/配下ではpilotが使用されます。

[
  {
    "patterns": [
      "https://.portal.example.jp/"
    ],
    "headers": [
      {
        "name": "X-Environment",
        "value": "prod"
      }
    ]
  },
  {
    "patterns": [
      "https://.portal.example.jp/pilot/"
    ],
    "headers": [
      {
        "name": "X-Environment",
        "value": "pilot"
      }
    ]
  }
]

ルールの追加を繰り返すと、管理者が想定していない上書きが起きやすくなります。同じヘッダー名を複数ルールで使う場合は、ルールの順番とURLの具体性を設計書に残しておきましょう。

Windowsのグループポリシーで設定する手順

Edgeと管理用テンプレートを更新する

対象端末のEdgeが153以降であることを確認します。

アドレスバーへ次のいずれかを入力すると、バージョンを確認できます。

edge://version

edge://settings/help

続いて、Microsoft Edge Enterprise向けの最新ポリシーテンプレートを取得し、msedge.admxと対応する言語用msedge.admlをセントラルストアまたはローカルのPolicyDefinitionsフォルダーへ配置します。古いADMXを使用していると、Edgeを153へ更新してもグループポリシーエディターにHttpHeaderInjectionが表示されません。(Microsoft Learn)

ポリシーを有効にする

グループポリシー管理エディターまたはローカルグループポリシーエディターで、次の場所を開きます。

コンピューターの構成 または ユーザーの構成
  > ポリシー
  > 管理用テンプレート
  > Microsoft Edge
  > Network settings
  > Configure HTTP Header Injection for specific URL patterns

ポリシーの一意名はHttpHeaderInjectionです。日本語版ADMLの更新状況によっては、ポリシー名やNetwork settingsが英語で表示されることがあります。公式のポリシーパスはAdministrative Templates/Microsoft Edge/Network settingsです。(Microsoft Learn)

ポリシーを「有効」にして、JSON形式の設定値を入力します。

グループポリシーの入力欄で改行や空白が問題になる場合は、次のように1行へ圧縮します。

[{"patterns":["https://.portal.example.jp/tenant-a/"],"headers":[{"name":"X-Organization-ID","value":"tenant-a"}]}]

コンピューター構成とユーザー構成を使い分ける

状況	推奨する適用単位
端末を使う全員が同じ組織・テナント	コンピューター構成
部署や利用者によって値が異なる	ユーザー構成
共有PCで複数テナントを使い分ける	ユーザー構成を優先
一部ユーザーだけ先行検証する	ユーザーグループへの限定適用
専用端末やキオスク端末	コンピューター構成を検討

共有PCへテナント固有のヘッダーをコンピューター単位で設定すると、別テナントの利用者にも同じ値が送信されます。利用者によって値が異なる環境では、セキュリティグループやOUを使い、ユーザー単位で対象を分離してください。

Windowsレジストリで直接設定する方法

Windowsでは、次のレジストリパスにREG_SZとして設定できます。(Microsoft Learn)

SOFTWARE\Policies\Microsoft\Edge

値の名前は次のとおりです。

HttpHeaderInjection

PowerShellでコンピューター単位の設定を作成する例は次のとおりです。

$config = @(
    @{
        patterns = @(
            'https://.portal.example.jp/tenant-a/'
        )
        headers = @(
            @{
                name  = 'X-Organization-ID'
                value = 'tenant-a'
            }
        )
    }
)

$json = ConvertTo-Json -InputObject $config -Depth 5 -Compress

$registryPath = 'HKLM:\SOFTWARE\Policies\Microsoft\Edge'

New-Item `
    -Path $registryPath `
    -Force | Out-Null

New-ItemProperty `
    -Path $registryPath `
    -Name 'HttpHeaderInjection' `
    -PropertyType String `
    -Value $json `
    -Force | Out-Null

Write-Output $json

HKLMへ設定する場合は、管理者権限でPowerShellを実行します。

ユーザー単位で設定する場合は、配布方式に応じて次のパスを使用します。

HKCU\SOFTWARE\Policies\Microsoft\Edge

本番環境では、端末ごとの手動レジストリ編集ではなく、グループポリシー、Intune、構成管理ツールなどから一元配布する方が適しています。

macOSの構成プロファイルで設定する方法

macOSでは、Edge用のプロパティリストまたは構成プロファイルにHttpHeaderInjectionキーを追加します。公式仕様では、配列と辞書を組み合わせてルールを記述します。(Microsoft Learn)

設定部分の例は次のとおりです。

<key>HttpHeaderInjection</key>
<array>
  <dict>
    <key>patterns</key>
    <array>
      <string>https://.portal.example.jp/tenant-a/</string>
    </array>
    <key>headers</key>
    <array>
      <dict>
        <key>name</key>
        <string>X-Organization-ID</string>
        <key>value</key>
        <string>tenant-a</string>
      </dict>
    </array>
  </dict>
</array>

IntuneやJamfなどで配布した後は、Windowsと同様にedge://policyで適用結果を確認します。

APIキーや認証トークンを設定してはいけない理由

HttpHeaderInjectionでは、Windowsならレジストリの文字列、macOSなら構成プロファイルとしてヘッダー値を配布します。その値は最終的に一致した宛先サーバーへ送信されます。(Microsoft Learn)

そのため、次のような値を入れる用途には向きません。

APIキー
Bearerトークン
OAuthアクセストークン
パスワード
クライアントシークレット
漏えいしただけで第三者が利用できる固定認証情報

HTTPSを使っても、宛先サーバー、TLSを終端するプロキシ、セキュリティ製品、Webサービスの運営者からはヘッダー値を確認できます。

また、端末上のポリシー値を閲覧できる権限を持つ管理者やソフトウェアから読み取られる可能性もあります。

運用上は、次のような単独では認証に使えない識別情報へ限定するのが安全です。

X-Organization-ID: tenant-a
X-Managed-Client: edge
X-Access-Group: accounting

ヘッダー値を認証判断に利用する場合も、その値だけで本人確認を完結させず、サーバー側の認証、デバイス証明書、Conditional Accessなどと組み合わせてください。

意図しない送信を防ぐための設計ポイント

ルートドメイン全体を対象にしない

次のような指定は、対象範囲が広すぎます。

example.jp

可能な限り、完全一致ホストを使います。

https://.portal.example.jp/

さらに、ヘッダーが必要なパスだけへ限定します。

https://.portal.example.jp/managed/

リダイレクト先も確認する

Webシステムでは、アクセス時に次のような別ホストへ移動することがあります。

認証用ホスト
CDN
別リージョンのホスト
ログインサービス
API専用ホスト
エラー表示用ホスト

最初に入力したURLだけを確認しても十分ではありません。開発者ツールのNetworkパネルで通信全体を記録し、どのホストへリクエストが送られているかを確認してください。

ヘッダーが必要なホストだけを個別に追加し、「念のため」という理由で親ドメイン全体を対象にしないことが重要です。

ページ遷移以外の通信も調べる

HttpHeaderInjectionは、URLパターンに一致したWebリクエストを対象とするポリシーです。トップページを開く操作だけに限定されるという仕様ではありません。(Microsoft Learn)

検証では、少なくとも次の通信を確認します。

fetchやXHRによるAPI通信
iframe内の通信
画像やスクリプトの読み込み
ファイルのアップロード、ダウンロード
Service Worker経由の通信
リダイレクト後の通信
拡張機能が発生させる通信

特に、別サイトを閲覧しているときでも、対象ホストの画像やAPIが埋め込まれていれば、そのリクエストがURLパターンへ一致する可能性があります。

利用者ごとに値が違う場合は適用範囲を分ける

テナントAの利用者へtenant-a、テナントBの利用者へtenant-bを設定する場合、同一端末へのコンピューターポリシーとして一律配布してはいけません。

次のようにユーザーグループを分けて配布します。

対象グループ	ヘッダー値
Tenant-A-Users	`tenant-a`
Tenant-B-Users	`tenant-b`
Pilot-Users	`pilot`

同じユーザーが複数の対象グループへ所属した場合、競合するポリシーの優先順位も確認してください。

適用状況をedge://policyで確認する

ポリシー配布後、対象端末のEdgeで次を開きます。

edge://policy

Microsoftは、Edgeポリシーの適用確認にedge://policyを使用する手順を案内しています。ローカルポリシーは通常すぐに表示されますが、設定中にEdgeを開いていた場合は、再読み込みやブラウザーの再起動が必要になることがあります。(Microsoft Learn)

確認する項目は次のとおりです。

HttpHeaderInjectionが表示されているか
ステータスがエラーになっていないか
ポリシーの適用元が想定どおりか
コンピューター単位かユーザー単位か
JSONの内容が想定どおりか
別の管理方式から値が上書きされていないか

edge://policyへ表示されない場合は、次の原因を確認します。

Edgeが153未満
ADMXが古い
GPOのリンク先やセキュリティフィルターが誤っている
対象ユーザーまたは端末がOUに含まれていない
別プロファイルで確認している
個人用Microsoftアカウントのプロファイルを使用している
ポリシーの同期が完了していない

実際のHTTPリクエストを検証する手順

edge://policyに正常表示されても、URLパターンの間違いや無効なヘッダーによって、期待した通信へ追加されていない可能性があります。

必ず実際のリクエストを確認してください。

開発者ツールで確認する

Edgeで対象サイトを開きます。
F12キーで開発者ツールを開きます。
Networkパネルを選択します。
必要に応じてPreserve logを有効にします。
Networkログを消去します。
対象操作を実行します。
対象リクエストを選択します。
Request Headersを確認します。
設定したヘッダー名と値が含まれているか確認します。

リダイレクトがある場合は、最終リクエストだけでなく、途中のすべてのリクエストを確認します。

対象外URLへ送られていないことを確認する

正常系だけでなく、ヘッダーが付いてはいけないURLもテストします。

設定が次の場合を考えます。

https://.portal.example.jp/tenant-a/

テスト先	期待結果
`https://portal.example.jp/tenant-a/`	付与される
`https://portal.example.jp/tenant-a/report`	付与される
`https://portal.example.jp/tenant-b/`	付与されない
`https://cdn.portal.example.jp/tenant-a/`	付与されない
`http://portal.example.jp/tenant-a/`	付与されない
`https://portal.example.jp/`	付与されない
`https://other.example.jp/tenant-a/`	付与されない

パスは前方一致として扱われるため、末尾のスラッシュも含めて設計することが重要です。パスとクエリでは大文字・小文字が区別されます。(Microsoft Learn)

サーバー側でも確認する

可能であれば、テスト用の受信ログや検証用エンドポイントを用意し、サーバー側で次を記録します。

受信したヘッダー名
受信した値
リクエスト先ホスト
パス
ユーザーまたはテスト端末
Edgeのバージョン
送信日時

インターネット上の公開HTTPヘッダー確認サービスへ、本番用のヘッダー値を送信してはいけません。検証時は秘密性のないダミー値を使用し、自組織が管理する環境で確認してください。

よくあるトラブルと対処方法

症状	主な原因	対処
グループポリシーに項目がない	ADMXが古い	最新の`msedge.admx`と`msedge.adml`へ更新
`edge://policy`に表示されない	Edgeが153未満、適用範囲の誤り	バージョン、OU、グループ、GPOリンクを確認
ポリシーは表示されるがヘッダーがない	URLパターンが一致していない	スキーム、ホスト、パス、ポートを確認
一部のURLだけ付与されない	パスの大文字・小文字が異なる	実際のリクエストURLと完全に比較
別のサブドメインにも送信される	ホスト名の先頭に`.`がない	完全一致形式へ変更
想定と異なる値が送信される	複数ルールが同じヘッダー名を設定	具体性とルール順を確認
Webアプリが設定した値が消える	ポリシー値が優先されている	ヘッダー名の重複を解消
拡張機能で変更できない	ポリシーが拡張機能より優先される	ポリシー設計を見直す
個人プロファイルだけ動かない	個人用Microsoftアカウントは対象外	職場・学校用の管理対象プロファイルで確認
Extended Stableで使えない	153がExtended Stable対象外	対応する後続メジャーバージョンを待つ
一部の設定だけ反映されない	無効な値や上限超過	500パターン、20ヘッダー、8KB制限を確認

安全な展開手順

本番環境へ一斉配布せず、次の順序で展開します。

対象通信を洗い出す

開発者ツールやサーバーログを使い、ヘッダーを必要とするホスト、パス、リダイレクト先を整理します。

秘密性のないテスト値を設定する

最初は次のような検証専用値を使用します。

X-Managed-Client-Test: edge153-pilot

パイロットグループだけへ配布する

管理者や検証担当者など、影響を把握できる少数のユーザーへ限定します。

正常系と異常系を検証する

対象URLに付与されることだけでなく、対象外URLへ付与されないことを確認します。

サーバー側の処理を確認する

プロキシ、WAF、CDN、アプリケーション、アクセスログ、キャッシュへの影響を確認します。

本番用の値へ切り替える

検証完了後も、単独で認証に利用できない値だけを設定します。

段階的に対象を拡大する

部署、OU、ユーザーグループ単位で範囲を広げます。

ロールバックを確認する

ポリシーを未構成へ戻し、edge://policyから設定が消えること、実際のリクエストからヘッダーが削除されることを確認します。

HttpHeaderInjection導入時に押さえるべきポイント

Microsoft Edge 153のHttpHeaderInjectionを使うと、管理対象Edgeから特定サイトへ送るHTTPリクエストに、組織IDやテナント識別値などの固定ヘッダーを追加できます。

安全に利用するための要点は次の3つです。

URLパターンをHTTPS＋完全一致ホスト＋必要なパスまで限定する
APIキーやトークンではなく、漏えいしても単独利用できない固定識別値だけを設定する
edge://policyだけでなく、開発者ツールとサーバーログで対象外URLへの送信有無も検証する

まずはEdgeのバージョンと更新チャンネルを確認し、最新の管理用テンプレートを導入してください。その後、秘密性のないテストヘッダーをパイロットグループへ配布し、正常系と対象外通信の両方を確認してから本番展開へ進むのが安全です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Edge 153のHttpHeaderInjectionとは？HTTPヘッダー注入の設定・検証・漏えい対策

Edge 153のHttpHeaderInjectionポリシーとは

対応環境と主な仕様

HttpHeaderInjectionが向いている用途と向いていない用途

HttpHeaderInjectionの設定形式

URLパターンはできるだけ狭く指定する

複数ルールが一致した場合の優先順位

Windowsのグループポリシーで設定する手順

Edgeと管理用テンプレートを更新する

ポリシーを有効にする

コンピューター構成とユーザー構成を使い分ける

Windowsレジストリで直接設定する方法

macOSの構成プロファイルで設定する方法

APIキーや認証トークンを設定してはいけない理由

意図しない送信を防ぐための設計ポイント

ルートドメイン全体を対象にしない

リダイレクト先も確認する

ページ遷移以外の通信も調べる

利用者ごとに値が違う場合は適用範囲を分ける

適用状況をedge://policyで確認する

実際のHTTPリクエストを検証する手順

開発者ツールで確認する

対象外URLへ送られていないことを確認する

サーバー側でも確認する

よくあるトラブルと対処方法

安全な展開手順

対象通信を洗い出す

秘密性のないテスト値を設定する

パイロットグループだけへ配布する

正常系と異常系を検証する

サーバー側の処理を確認する

本番用の値へ切り替える

段階的に対象を拡大する

ロールバックを確認する

HttpHeaderInjection導入時に押さえるべきポイント

この記事を書いた人

コメント

コメントするコメントをキャンセル

Edge 153のHttpHeaderInjectionとは？HTTPヘッダー注入の設定・検証・漏えい対策

Edge 153のHttpHeaderInjectionポリシーとは

対応環境と主な仕様

HttpHeaderInjectionが向いている用途と向いていない用途

HttpHeaderInjectionの設定形式

URLパターンはできるだけ狭く指定する

複数ルールが一致した場合の優先順位

Windowsのグループポリシーで設定する手順

Edgeと管理用テンプレートを更新する

ポリシーを有効にする

コンピューター構成とユーザー構成を使い分ける

Windowsレジストリで直接設定する方法

macOSの構成プロファイルで設定する方法

APIキーや認証トークンを設定してはいけない理由

意図しない送信を防ぐための設計ポイント

ルートドメイン全体を対象にしない

リダイレクト先も確認する

ページ遷移以外の通信も調べる

利用者ごとに値が違う場合は適用範囲を分ける

適用状況をedge://policyで確認する

実際のHTTPリクエストを検証する手順

開発者ツールで確認する

対象外URLへ送られていないことを確認する

サーバー側でも確認する

よくあるトラブルと対処方法

安全な展開手順

対象通信を洗い出す

秘密性のないテスト値を設定する

パイロットグループだけへ配布する

正常系と異常系を検証する

サーバー側の処理を確認する

本番用の値へ切り替える

段階的に対象を拡大する

ロールバックを確認する

HttpHeaderInjection導入時に押さえるべきポイント

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル