robots.txtに機密パスを列挙していないか？Disallowの危険性・正しい隠し方・診断基準

robots.txtに機密パスを列挙していないとは

robots.txtに機密パスを列挙していないとは、robots.txtの Disallow 行に、管理・バックアップ・内部用を示すパスを書いていない状態のことです。

robots.txtは、検索エンジン等のクローラーに「どのURLを巡回してよいか」を伝えるためのテキストファイルで、サイトのルート（/robots.txt）に置きます。誰でも取得できるファイルであり、記載したパスはそのまま公開情報になります。

# 好ましくない例：管理画面とバックアップの場所を公開している
User-agent: *
Disallow: /admin/
Disallow: /backup/

管理画面やバックアップ置き場を検索結果に出したくないという理由で、Disallow: /admin/ や Disallow: /backup/ のように書いてしまうと、「ここに重要なものがある」という地図を攻撃者に渡すことになります。RFC 9309は、robots.txtが有効なセキュリティ対策の代替ではないことを明記しており、OWASP WSTGでもrobots.txtは調査（偵察）の最初の確認対象です。

この項目は、robots.txtの Disallow 行に、管理・バックアップ・内部用を示す代表的なパス名が列挙されていないかを確認します。サイトマップに非公開ページが載っている問題は「sitemapに非公開ページを含めていない」で別に確認します。

robots.txtの仕様とセキュリティ上の位置付け

robots.txtの仕様の要点（RFC 9309）

• User-agent、Allow、Disallow の行でグループを構成します。Disallow のパスは前方一致で評価されます。
• フィールド名の後のコロンの前後には空白を置けます（Disallow : /x も有効）。
• クローラーは少なくとも5回のリダイレクトを追跡すべきとされています。
• 4xxのときクローラーはすべてのURLにアクセスしてよく、5xxのときは全面的に禁止と見なします。
• 解析上限は少なくとも500KiBです。キャッシュは原則24時間までです。
• 第3節: robots.txtは有効なコンテンツ保護策の代替ではなく、列挙したパスは公開され発見可能になります。WSTGもクローラーが Disallow を意図的に無視し得ることを指摘し、最新版（latest）ではAIクローラーがrobots.txtを無視する例にも触れています。

検索結果に出さない方法との違い

Googleの公式ドキュメントは、robots.txtが「Googleの検索結果にページを表示させないための仕組みではない」と説明し、robots.txtで拒否したページでも他サイトからリンクされていればURLが検索結果に出ることがあるとしています。検索結果から除外したい場合は noindex（metaタグまたは X-Robots-Tag ヘッダー）を使い、そもそも見られてはいけないものは認証で保護するか、公開領域から削除します。

記述パターンの評価

本当に隠したいパスを書く代わりに、上位の無関係な名前のディレクトリでまとめる工夫も見られますが、それも「隠すことによる安全」にすぎません。保護は認証で行い、robots.txtには公開しても困らない情報だけを書く、という原則で整理するのが確実です。

robots.txtについてよくある誤解

• 「Disallowすれば誰も見られない」：robots.txtはお願いであり、ブラウザや攻撃ツールはまったく参照しません。
• 「管理画面を検索結果から隠すためにDisallowが必要」：管理画面は認証で保護されていれば検索結果に本文は載りません。noindexを返す、あるいはインターネットから到達できないネットワークに置くのが適切です。
• 「robots.txtを置かないとよくない」：robots.txtは任意です。置かない場合、クローラーはすべてのURLを巡回してよいと解釈します。

robots.txtに機密パスを列挙していないの診断基準（セキュリティAIチェッカー）

取得方法

• 診断の最終URLのオリジンに対し /robots.txt をGETします（リダイレクトは追跡しない、タイムアウト4秒、最大100,000バイト。上限を超える応答は先頭部分で打ち切って判定）。
• ステータス200で、本文がHTMLではない（先頭1,000文字に <!doctype html>、<html>、<head>、<body>、<div>、<script> がない）ものをrobots.txtとして評価します。

判定条件

本文に次の正規表現（大小文字を区別しない）に一致する行があるかを確認します。

disallow\s*:\s*/(?:admin|backup|private|internal|secret)

/admin、/administrator、/backup、/backups、/private、/internal、/secret などで始まるパスが対象です。

× 要改善（fail）はありません。パス名の列挙だけでは実害の有無が判断できず、実際に保護されているかは別途確認が必要なため、「要確認」の △ にしています。

判定の限界

• 代表的な5語のみを対象にしています。/kanri/（管理）、/test/、/staff/、/cms/ など日本語ローマ字や製品固有のパスは対象外です。
• Disallow: /wp-admin/ のように語の前に別の文字列がある場合は一致しません（WordPressの管理画面の場所は広く知られており、列挙による追加の情報漏えいは小さいため）。
• 列挙されたパスが実際に認証で保護されているかは確認しません。
• robots.txtへのリダイレクトは追跡しないため、/robots.txt を別URLへ転送している構成は対象外になります。

自治体サイトでの判定例

robots.txtに機密パスを書くとどんなリスクがあるか

• 攻撃対象の発見を容易にする：管理画面、旧システム、バックアップ置き場のURLが分かると、攻撃者はそこに絞ってパスワード総当たりや既知脆弱性の探索を行えます。
• 保護漏れの露呈：「検索に出なければよい」という考えで認証をかけずに置かれた資料（内部向け文書、個人情報を含む名簿等）がDisallowに列挙されていると、URLを直接開くだけで閲覧されます。
• 検索結果へのURL露出：robots.txtで拒否したページでも、外部からリンクされるとURLだけが検索結果に出ることがあります。

バックアップなどの管理ファイルそのものが取得できる問題は、「代表的な管理ファイルが公開されていない」で確認します。

robots.txtの機密パスへの対策（Apache・nginx・IIS・Next.js）

1. まず保護する

列挙されているパスについて、次のいずれかを行います。

• 不要なら削除する。
• 必要なら認証（ID・パスワード、多要素認証）やIP制限をかける。管理画面は庁内ネットワークやVPNからのみ到達できるようにする。

Apache（.htaccess）で管理画面をIP制限する例:

<IfModule mod_authz_core.c>
  <If "%{REQUEST_URI} =~ m#^/admin(/|$)#">
    Require ip 192.0.2.0/24
  </If>
</IfModule>

nginx:

location ^~ /admin/ {
    allow 192.0.2.0/24;
    deny all;
}

IIS：「IPアドレスおよびドメインの制限」機能で /admin 仮想ディレクトリに許可リストを設定します。

2. 検索結果から外したいページはnoindexにする

# Apache: 特定ディレクトリにnoindexヘッダーを付ける
<If "%{REQUEST_URI} =~ m#^/kanri/#">
  Header set X-Robots-Tag "noindex, nofollow"
</If>

location ^~ /kanri/ { add_header X-Robots-Tag "noindex, nofollow" always; }

Next.js（Vercel）では next.config.js の headers() で X-Robots-Tag を返すか、ページの metadata.robots で index: false を設定できます。noindexを読ませるため、そのパスはrobots.txtで拒否しないでください。

3. robots.txtを整理する

User-agent: *
Disallow: /cgi-bin/
Disallow: /search/
Sitemap: https://www.city.example.lg.jp/sitemap.xml

本当に負荷対策としてクロールを止めたいパスだけを残し、管理・内部用のパスは削除します。

4. 確認方法

curl -s https://www.city.example.lg.jp/robots.txt | grep -iE 'disallow\s*:\s*/(admin|backup|private|internal|secret)'
# 列挙していたパスに未認証でアクセスできないこと
curl -s -o /dev/null -w '%{http_code}\n' https://www.city.example.lg.jp/admin/

整理後はセキュリティAIチェッカーで再診断し、根拠欄が「代表的な機密パス名は確認されません。」になっていることを確認します。

検索流入を失わないための注意点（ガードレール）

• robots.txtからパスを消す前に、そのパスの保護（削除・認証）を済ませてください。順序が逆だと、検索エンジンが巡回して内容が索引に載るおそれがあります。
• Disallow: / を誤って本番に残すと、サイト全体が検索結果から消えていきます。テスト環境からのコピー時に注意します。
• CMSが自動生成するrobots.txtを使っている場合は、CMS側の設定画面で編集します。
• 整理の前後で、Google Search Consoleのrobots.txtレポートやURL検査で、主要ページがクロール可能なままであることを確認します（旧「robots.txtテスター」は2023年に廃止されています）。

よくある質問（FAQ）

参考資料

• RFC 9309 Robots Exclusion Protocol
• OWASP WSTG-INFO-03 Review Webserver Metafiles for Information Leakage（stable）
• OWASP WSTG-INFO-03 最新版（AIクローラーの記述を含む）
• OWASP ASVS 5.0.0 V13 Configuration
• Google 検索セントラル robots.txt の概要

「robots.txtに機密パスを列挙していない」と関連する診断項目

• sitemapに非公開ページを含めていないmedium
• 代表的な管理ファイルが公開されていないcritical
• サーバーバージョンを露出していないlow
• 秘密情報らしき文字列がないcritical
• ソースマップ参照を公開していないmedium
• 生成ツール情報を露出していないlow
• 本番HTMLにconsole.logを残していないlow
• security.txtを公開low