同一オリジンを限定巡回とは？確認ページ数の意味・巡回のルール・診断基準

同一オリジンを限定巡回とは

同一オリジンを限定巡回とは、セキュリティAIチェッカーが、トップページから直接リンクされた同一オリジン（スキーム・ホスト・ポートが一致）のページを、GETのみで最大5ページまで確認する仕組みと、その実施結果の記録です。

4/5ページをGETのみで確認し、取得失敗は1件です。

この項目は、診断AIが「トップページ以外にどのページを、何ページ確認できたか」を利用者に示すためのものです。セキュリティ上の良否を評価するものではなく、重みは0で総合スコアに影響しません。

Webサイトのセキュリティ設定は、ページごとに異なることがよくあります。トップページにはセキュリティヘッダーが付いているのに、CMSの別機能や外部委託のサブシステム（電子申請、施設予約、問い合わせフォーム）では付いていない、ログインページだけキャッシュ制御が不適切、といった状態です。OWASP WSTGでも、アプリケーションの入口（WSTG-INFO-06）や実行経路（WSTG-INFO-07）を把握することが、テストの前提として位置付けられています。

一方、公開サイトを無制限に巡回すると、対象サーバーに負荷を掛け、意図しない操作（ログアウト、削除、購読解除など）を引き起こすおそれがあります。そこで本診断は、同一オリジンに限定し、GETのみで、最大5ページという上限を設けた「限定巡回」を行います。本項目はその実施結果（確認ページ数と取得失敗数）を記録し、複数ページを対象とする他の判定がどの範囲に基づくかを明らかにします。

なぜ巡回を「同一オリジン・GETのみ・5ページ」に限定するのか

限定する3つの理由

• 安全性：GET以外のメソッドは状態を変更する可能性があるため使いません。GETであっても、URLのパスに logout・signout・delete・remove・destroy・unsubscribe を含むものは、実装によっては状態を変えるため巡回対象から外します。
• 負荷：自治体サイトは小規模なサーバーで運用されていることも多く、短時間に大量のリクエストを送るとサービスに影響します。上限5ページはこの配慮によるものです。
• 範囲の明確化：同一オリジン（スキーム・ホスト・ポートが一致）に限ることで、他組織のサイトを診断してしまうことを防ぎます。外部ドメインへのリダイレクトで到達したページも対象外とします。

巡回するページの優先順位

限られた件数で重要な画面を確認するため、トップページのHTMLから候補を集め、次の優先度で選びます。

CSS・JavaScript・JSON・XML・テキスト・CSV・画像・PDF・Office文書・ZIP・フォントなどの静的ファイル（拡張子で判定）は、ページとしての巡回対象から除外します。

限定巡回についてよくある誤解

• 「5ページで問題がなければサイト全体が安全」：限定巡回は代表的な画面の抽出確認です。リンクされていない管理画面や、ログイン後の画面は確認できません。
• 「取得失敗は脆弱性」：タイムアウト、外部ドメインへの転送、WAFによる遮断など、失敗の原因は様々です。失敗が多い場合は、他の複数ページ判定の根拠が少ないことを意味します。

同一オリジンを限定巡回の診断基準（セキュリティAIチェッカー）

巡回の手順

1. 入力URLを取得し（リダイレクトは最大4回、タイムアウト15秒）、最終URLのHTMLを得ます。トップページがHTTP 403または429を返した場合は、対象サイト側のアクセス制限とみなし、レポートを返さず診断全体をエラーにします。
2. HTMLから <a href>、<form action>、引用符で囲まれた /api/... 文字列を抽出し、相対URLを絶対URLへ変換します。href は引用符で囲まれた値だけを読み、属性値に < や > を含むタグは抽出しません。フラグメント（#以降）は除去し、認証情報付きURLやhttp/https以外のスキームは捨てます。
3. 最終URLと同一オリジンの候補だけを残し、除外語を含むパスと静的ファイルを外します。
4. 優先度順に並べ、最大4件を選びます（トップページと合わせて最大5ページ）。
5. 各候補をGETで取得します（リダイレクト最大3回、タイムアウト7秒、最大500,000バイト）。取得後の最終URLが別オリジンになった場合は失敗として扱います。
6. 取得に成功したページ（HTTPステータスは問わない）を、Cookie・ヘッダー整合性・no-store等の複数ページ判定に使います。

診断サーバー側の安全策

全通信は、名前解決したIPアドレスが内部ネットワーク（プライベートアドレス、ループバック等）でないことを確認してから接続し、診断サーバーが内部資源へ到達しないようにしています。本文は展開せずに読むため、リクエストには Accept-Encoding: identity を付けて無圧縮の応答を求めます。

アクセスを制限された場合の扱い

診断の最後にはトップページをもう一度取得します。HTTP 403/429または無応答に変わっていて、診断中の応答も末尾まで拒否・無応答が続いていた場合は、途中からアクセスを制限されたものとして、レポートを返さず診断全体をエラーにします（数分おいて再実行）。拒否が最後の再取得だけなら、レポートは返します。レポートの項目はREADMEの診断項目表と同じ順に並びます。

判定条件

• 根拠欄には「確認ページ数／上限5」と「取得失敗件数」を表示します（例「4/5ページをGETのみで確認し、取得失敗は1件です」）。
• 重み0のため総合スコアは変わりませんが、判定状態が「対象外」ではないので判定可能率の分子に数えられます。
• 重大度はinfoです。

自治体サイトでの判定例

最後の例で、診断中の応答から最後のトップページ再取得まで403/429・無応答が続いた場合は、判定を出さず診断エラーになります。

巡回結果はどの判定に使われるか

診断結果画面とテキストレポートには「確認ページ数／上限」が表示され、診断APIの応答には上限（5）、確認したページのURL一覧、API候補、取得失敗件数が含まれます。各ページの結果は次の判定の根拠になります。

このため、巡回ページ数が少ないと、これらの判定は「対象外」になりやすく、判定可能率が下がります。重要画面がトップページから直接リンクされていない場合は、そのURLを入力して個別に診断することで補えます。

判定の限界

• JavaScriptで生成されるリンク、ログイン後のページ、リンクされていないページは対象外です。
• 巡回は1階層のみ（トップページから直接リンクされたページ）です。
• 取得した応答が404等のエラーでも「取得成功」として他の判定に使われます。

巡回範囲が狭いとどんなリスクがあるか

本項目自体は脆弱性を示しません。注意すべきは「診断範囲が狭いことによる見落とし」です。

• サブシステムの設定不備の見逃し：自治体サイトでは、本体CMSと、委託先が運用する予約・申請・アンケート等のシステムが同一ドメイン上に混在することがあります。限定巡回で拾えなかった画面にセキュリティヘッダーの欠落や不適切なCookie設定が残っている可能性があります。
• 安心の誤認：確認ページ数が少ない（1/5など）状態で総合スコアが高くても、それはトップページの設定を主に反映した結果です。
• 巡回失敗の背後にある問題：取得失敗が多い場合、WAFの過剰な遮断や応答遅延など、利用者にも影響する可用性の問題が隠れていることがあります。

診断の網羅性を高める方法・対策（Apache・nginx・IIS・Next.js）

本項目は修正対象ではありませんが、診断の網羅性を高め、結果を正しく読むための対応を示します。

重要画面を手動で追加診断する

ログイン画面、電子申請・施設予約・問い合わせフォーム、管理画面のURLを、個別に診断対象URLとして入力し、同じ項目を確認します。

全ページへ同じ設定を適用する

ページ間で設定がばらつかないよう、セキュリティヘッダーはアプリケーションごとではなく、Webサーバーやリバースプロキシの共通設定で付与します。

# Apache: サイト全体に適用（.htaccessをドキュメントルートに配置）
<IfModule mod_headers.c>
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>

# nginx: serverブロックに記述（locationでadd_headerを使うと継承されない点に注意）
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;

<!-- IIS: web.config -->
<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-Content-Type-Options" value="nosniff" />
      <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

// Next.js: next.config.ts で全パスに適用
async headers() {
  return [{ source: "/:path*", headers: [
    { key: "X-Content-Type-Options", value: "nosniff" },
    { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
  ] }];
}

取得失敗の原因を確認する

curl -s -o /dev/null -w '%{http_code} %{time_total}s %{redirect_url}\n' https://www.city.example.lg.jp/login/

タイムアウトが続く場合は、サーバー負荷やWAFの設定を確認します。診断ツールのアクセスを遮断する設定自体は問題ではありませんが、正規の利用者まで遮断していないか確認します。

サイトを壊さないための注意点（ガードレール）

• 全体設定でヘッダーを追加する前に、iframe埋め込みを行うサブシステム（X-Frame-Options）や外部連携（CSP）が壊れないか、検証環境で確認します。
• 状態を変更する操作（ログアウト、削除等）をGETで実装している場合は、POST＋CSRFトークンへ改めます。クローラーや先読み機能が誤って実行するおそれがあるためです。

よくある質問（FAQ）

参考資料

• OWASP Web Security Testing Guide v4.2 Information Gathering（WSTG-INFO-06・07）
• OWASP Web Security Testing Guide

「同一オリジンを限定巡回」と関連する診断項目

• ページ間のセキュリティヘッダー整合性medium
• 認証関連ページのno-storehigh
• CookieのDomain/Path範囲medium
• Cookie接頭辞の要件high
• Partitioned Cookieの要件medium
• Cookie名・値のサイズ上限medium
• 任意Originを反射しないhigh
• 動的CORSでVary: Originを返すmedium