機微パスとは
外部攻撃面の Web 入口では、 トップページ以外に代表パスへの応答を確認することがあります。 そのうち、ソースコード・設定・認証情報の手がかりになりうるパスを まとめて機微パスと呼ぶことがあります。
/.git/HEAD— Git リポジトリの誤公開（履歴から秘密が復元されうる）/.env、/config.php.bak等 — 設定・資格情報の残骸/admin、/console— 管理 UI（別記事）/.well-known/— 用途次第で公開が正しいものも（security.txt 等）
「一覧に載っていないから安全」ではなく、 第三者が既知のパス名を試す、または 検索エンジン・ログから URL が漏れる、という前提で整理します。
403 でも「存在の示唆」になりうる
サーバーが 403 Forbidden を返す場合、 「ブロックされているから問題ない」と判断しがちです。 攻撃面レビューでは、404 との応答の差から 「パス自体は存在する」と記録することがあります。
架空の報告書サンプルでは、
https://example.co.jp/.git/HEAD が HTTP 403 で、
「パスの存在が示唆される応答」として重要度中（F-16）を挙げています。
同報告書では、管理系 URL との同時存在（F-11）も
高重要度で整理されています。
なぜ起きるか
- デプロイミス —
.gitごと Web ルートに配置 - バックアップ放置 — 編集時の
.bakが公開ディレクトリに残る - リバースプロキシの設定 — 特定パスだけ別 upstream に流れる
- 検証環境の残骸 — 非本番サブドメインに限定されていると思いきや、本番にも残る
外部攻撃面レビューで「見る」こと（例）
| 観点 | 確認する内容（例） |
|---|---|
| 代表パス | 契約内のパスリストへの GET/HEAD 応答（ステータス・長さ・リダイレクト） |
| 相関 | 同一ホストの管理 UI・SSH 公開など、他所見との組み合わせ |
| 記録 | URL・ステータスコード・確認日時 — 報告書の所見 ID（F-xx）として整理 |
目的はリポジトリの全取得や秘密の抽出ではなく、 公開応答として残っている事実と 優先して非公開化すべき URLの共有です。 ファイル内容のダウンロードや履歴復元まで行う調査は別スコープです。
対応の方向性（御社・ベンダー側）
- 即時 —
/.git等へのアクセスを Web サーバー設定で拒否、実体を公開ディレクトリ外へ移動 - 漏洩想定 — 誤公開期間中にコミットされていた秘密（API キー等）のローテーション
- 再発防止 — デプロイ手順・CI の除外ルール、公開前チェック
- 再確認 — 次回の攻撃面レビューで応答が 404 等に変わったか比較
含まないこと（よくある誤解）
.git履歴のダンプやソースコード窃取の実証- Web サーバー設定変更・WAF ルール追加の代行
- 社内 Git サーバー・非公開リポジトリの調査
- ペンテスト（別契約）
調査データは閉域環境内で扱います
調査結果は閉域環境内のみで保管・処理します。 契約範囲内の HTTP プローブは発生します。 報告書は基本メールで納品し、調査画面のログインはお渡ししません。