レガシーなクロスドメイン許可を制限（X-Permitted-Cross-Domain-Policies）とは？診断基準と対策

レガシーなクロスドメイン許可を制限する（X-Permitted-Cross-Domain-Policies）とは

レガシーなクロスドメイン許可を制限する対策とは、レスポンスヘッダー X-Permitted-Cross-Domain-Policies を返して、Adobe Flash Player や Adobe Acrobat/Reader などのクライアントが参照する「クロスドメインポリシーファイル」（通常はサイト直下の crossdomain.xml）のうち、どれを有効とみなすかを宣言することです。

X-Permitted-Cross-Domain-Policies: none

none を指定すると、そのサーバー上のポリシーファイルはすべて無効になり、これらのクライアントから他ドメインのデータを読み取る許可を与えなくなります。

Flash Player は2020年末でサポートが終了していますが、Adobe のドキュメントによれば Acrobat/Reader は現在もクロスドメインポリシーファイルを利用します。自治体サイトでは PDF の申請様式やフォームを多数配布しているため、古い crossdomain.xml が残っていないか、意図しない許可を出していないかを確認する意味があります。対策はヘッダー1行で、通常のブラウザ表示には影響しません。

クロスドメインポリシーファイルの仕組み

crossdomain.xml とは

Flash や Acrobat のコンテンツが、自分の配信元とは別のドメインへデータを要求するとき、クライアントは要求先ドメインのポリシーファイル（既定ではルートの /crossdomain.xml）を取得し、要求元ドメインが許可されているかを確認します。例えば次のようなファイルは、すべてのドメインからの読み取りを許可します。

<?xml version="1.0"?>
<cross-domain-policy>
  <allow-access-from domain="*" />
</cross-domain-policy>

Adobe のドキュメントは、Acrobat/Reader がフォームデータの送信、SOAP リクエスト、Net.HTTP.request など、複数ドメインへのデータ要求でこの仕組みを使うと説明しています。

メタポリシーと X-Permitted-Cross-Domain-Policies の値

ルートのポリシーファイル（マスターポリシー）に加え、サブディレクトリに置いたポリシーファイルや、スクリプトが動的に生成した応答もポリシーとして扱われることがあります。これを制御するのが「メタポリシー」で、マスターポリシー内の <site-control> 要素か、このヘッダーで宣言します。

Adobe のドキュメントは、暗黙の動作に頼らずメタポリシーを明示的に宣言するよう勧めています。none-this-response については、サーバー側スクリプトがポリシーファイルとして解釈される応答を生成することを防ぐための仕組みと説明しています。

Silverlight の clientaccesspolicy.xml

Microsoft Silverlight は clientaccesspolicy.xml を参照し、なければ crossdomain.xml も参照しました。Silverlight もサポートが終了しています。古いシステム移行の名残でこれらのファイルが残っていることがあります。サイト内で Flash などの廃止技術を使い続けていないかは「廃止されたクライアント技術を使用していない」の項目で確認します。

クロスドメイン許可についてよくある誤解

• 「Flash は終わったので関係ない」：Flash Player はサポート終了済みですが、Acrobat/Reader はクロスドメインポリシーを参照します。また、crossdomain.xml に domain="*" が残っていると、診断ツールや第三者から「設定が甘いサイト」と判断されます。
• 「このヘッダーでブラウザの CORS も制限できる」：関係ありません。ブラウザの JavaScript によるクロスオリジン通信は CORS（Access-Control-Allow-Origin）で制御されます。CORS の設定は「危険なCORSワイルドカードがない」で確認します。
• 「none にすると PDF が開けなくなる」：PDF の表示やダウンロードには影響しません。影響があるのは、PDF 内の JavaScript やフォームが「別ドメイン」の本サーバーからデータを読み取る場合などに限られます。

レガシーなクロスドメイン許可を制限の診断基準（セキュリティAIチェッカー）

取得方法

• 入力URLへ GET を1回送り、リダイレクト（最大4回）後の最終応答の X-Permitted-Cross-Domain-Policies ヘッダーを評価します。値はカンマで分割し、各値の前後の空白を除いて判定します（大文字小文字は区別しません）。
• /crossdomain.xml や /clientaccesspolicy.xml の取得は、この項目では行いません。

判定条件

• none-this-response は「この応答をポリシーファイルとして扱わない」という指定にとどまり、サイト全体のメタポリシーを制限するものではないため、○ にはしません。
• 根拠欄にはヘッダー値、または「X-Permitted-Cross-Domain-Policiesがありません。」を表示します。
• × を使わないのは、ヘッダーがないことだけでは、実際に危険なポリシーファイルが存在するかが分からないためです。ヘッダーは、ポリシーファイルが誤って配置された場合の保険として機能します。
• 重大度 low・重み1は、影響するクライアントが限られていることを反映しています。

自治体サイトでの判定例

クロスドメイン許可を制限しないとどんなリスクがあるか

攻撃シナリオ

1. 緩いポリシーファイルの悪用：過去に Flash コンテンツのために配置した crossdomain.xml に allow-access-from domain="*" が残っている。攻撃者が用意したコンテンツ（PDF など、ポリシーファイルを参照するクライアントで動くもの）から、住民がログインした状態の本サイトへ要求を送り、応答を読み取る。ログイン後の画面や API があるサイトでは個人情報の漏えいにつながります。
2. アップロードファイルをポリシーファイルとして悪用：メタポリシーが緩い場合、利用者がアップロードした XML ファイルや、スクリプトが生成した応答がポリシーファイルとして解釈され、攻撃者が自分のドメインを許可するポリシーを作り出せる可能性があります。none や master-only はこれを防ぎます。
3. CSRF 対策の迂回：クロスドメインでの読み取りが許可されると、ページ内の CSRF トークンを読み取られ、フォーム送信の保護が無効になるおそれがあります。

想定される被害

• ログインが必要なページや API の内容（申請情報、個人情報）の読み取り
• CSRF トークンの窃取による不正な操作

現在は対応するクライアントが限られ、主要ブラウザ自体はこの仕組みを使わないため、リスクは限定的です。ただし、残置されたポリシーファイルは長期間気付かれないことが多く、ヘッダーによる明示的な無効化は低コストの予防策です。

クロスドメイン許可を制限する設定方法（Apache・nginx・IIS・Next.js）

対応の手順

1. 残置ファイルの確認：/crossdomain.xml と /clientaccesspolicy.xml が存在するか確認し、不要なら削除します。必要な場合は domain="*" を使わず、具体的なドメインだけを許可します。
2. ヘッダーの付与：全応答に X-Permitted-Cross-Domain-Policies: none を付けます。どうしても crossdomain.xml を使う必要がある場合だけ master-only にします。

Apache（.htaccess）

<IfModule mod_headers.c>
  Header always set X-Permitted-Cross-Domain-Policies "none"
</IfModule>

nginx

add_header X-Permitted-Cross-Domain-Policies "none" always;

IIS（web.config）

<httpProtocol>
  <customHeaders>
    <add name="X-Permitted-Cross-Domain-Policies" value="none" />
  </customHeaders>
</httpProtocol>

Next.js（Vercel）

// next.config.js
module.exports = {
  async headers() {
    return [{
      source: "/:path*",
      headers: [{ key: "X-Permitted-Cross-Domain-Policies", value: "none" }],
    }];
  },
};

サイトを壊さないための注意点

• 職員向けに、PDF フォームから別ドメインのサーバーへデータを送受信する仕組み（古い電子申請や集計システムなど）を使っていないか確認します。そうした仕組みが本サーバーのポリシーファイルに依存している場合、none にすると動作しなくなります。その場合は master-only とし、crossdomain.xml の許可ドメインを最小限にします。
• ヘッダーの付与は Web サーバーの共通設定で行い、CMS とサーバーの二重付与を避けます。

設定後の確認方法

curl -sI https://www.example.lg.jp/ | grep -i x-permitted-cross-domain-policies
# 残置ポリシーファイルの確認（404 であれば存在しない）
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.lg.jp/crossdomain.xml
curl -s -o /dev/null -w "%{http_code}\n" https://www.example.lg.jp/clientaccesspolicy.xml

ポリシーファイルが 200 を返す場合は、内容に domain="*" が含まれていないかを確認します。ソフト404（存在しないURLでも 200 とトップページを返す構成）の場合は、本文が XML かどうかで判断してください。設定後はセキュリティAIチェッカーで再診断し、根拠欄に none が表示されていることを確認します。

よくある質問（FAQ）

参考資料

• OWASP Secure Headers Project（X-Permitted-Cross-Domain-Policies）
• OWASP Secure Headers Project 推奨ヘッダー値（headers_add.json）
• Adobe: Cross Domain Configuration（Acrobat/Reader）
• OWASP ASVS 5.0.0 V3 Web Frontend Security（V3.7.1）
• OWASP WSTG-CONF-08 RIA Cross Domain Policy
• CWE-942

「レガシーなクロスドメイン許可を制限」と関連する診断項目

• 廃止されたクライアント技術を使用していないhigh
• 危険なCORSワイルドカードがないhigh
• クリックジャッキング対策high
• MIMEスニッフィング対策medium
• Referrer-Policymedium
• Permissions-Policylow
• Cross-Origin-Opener-Policylow
• Cross-Origin-Embedder-Policylow