GitHubに上げているサイトのリポジトリは「コードが読める」のは当然として、攻撃対象面を広げる情報が意図せず残ることがあります。漏洩というほどの致命傷ではない。けれど攻撃者の偵察コストを下げる材料にはなります。
特によく残るのは、generator メタタグ、旧HTML、hidden input の 3 種類。それぞれの対処を整理します。
フレームワークバージョン: generator メタタグ
多くのSSGやCMSは、生成したHTMLに <meta name="generator"> を入れます。
<meta name="generator" content="Astro v6.3.3">
<meta name="generator" content="WordPress 6.4">
<meta name="generator" content="Hugo 0.140.0">これがあると、サイトを開いたブラウザのDevToolsで誰でもフレームワークとバージョンが分かります。
リスクは2つ。既知の脆弱性 (CVE) を狙った攻撃の偵察に使われる。「v6.3.3はXが動く」のようなバージョン固有の攻撃手法に標的化されます。
対処は、AstroならBaseLayoutから削除すれば終わり。
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<!-- 削除: <meta name="generator" content={Astro.generator} /> -->
</head>WordPressなら functions.php で remove_action('wp_head', 'wp_generator');。Hugoならテーマ側で対応します。
「フレームワークを利用していること」自体はHTTPヘッダー、CSSクラス名、ビルド成果物から判別可能なケースが多く、generator 削除で完全に匿名化できるわけではありません。それでもバージョンまで露出するのは避けるべき。攻撃者の偵察コストは確実に上がります。
移行作業で残った旧HTMLや設定
WordPressや旧CMSからSSGにリプレースしたサイトのリポジトリには、移行参照用に旧HTMLスナップショットを置くことがあります。
migrate/
├── raw-html/
│ ├── home.html ← GTM ID、Dynatrace エンドポイント、旧プラグインURL
│ ├── contact.html
│ └── ...
├── wp-status.txt ← WPプラグイン一覧、管理画面URL
└── wp-uploads-and-options.txtこれらは本番デプロイ対象ではない (Astroなら src/ 外、distに含まれない) ので、運用上の影響はありません。けれど公開リポジトリにしている場合はGitHubで誰でも見られます。
リスクは、旧サイトに紐付いていたGTMコンテナID、Dynatrace Application ID、Google Analytics ID等の露出。旧CMSの管理画面URL、プラグイン構成、バージョンが推測されること。ベンダー固有のエンドポイントや internal config が漏れること。
対処の選択肢は 3 つ。
第一に、追跡を外して履歴も削除する方法。.gitignore への追加だけでは追跡済みファイルや過去履歴は消えません。git rm --cached migrate/raw-html/ で以後の追跡を外し、過去履歴は git filter-repo (旧 git filter-branch) で書き換えます。履歴書き換えはチーム作業に影響するので、リモートと整合させる段取りが必要。
第二に、プライベートな場所に移動する方法 (Google Drive、社内Notion、プライベートリポジトリ)。参照用には残しつつ公開から退避します。
第三に、そのまま残しつつ旧IDをすべて無効化する方法 (GTMコンテナ削除、APIキー失効、エンドポイント廃止)。漏れていても害がない状態にします。
機能影響が小さい順は 2、3、1。本番切替後 (旧IDが完全に使われなくなった後) なら 1 が最も安全です。
フォームのhidden inputに書かれた識別子
<input type="hidden" name="access_key" value="abc-123-xyz" />
<input type="hidden" name="redirect" value="https://example.com/thanks/" />
<input type="hidden" name="subject" value="【ブロトソル】お問い合わせ" />Web3Forms 等のSaaSフォームで access_key を hidden input に書くのは仕様通りで、これ自体は問題ではありません (公開識別子なので隠せない)。
重要なのは、access_key 以外のhidden field です。redirect URL は自サイトのURL構造を露出 (大規模問題ではないが偵察情報)。subject、from_email、to_email は内部メールアドレスや件名規約を露出。webhook_url はSlack等のincoming webhookが hidden に書かれていると致命的です。
リスクは、内部メアドがスクレイピングされ spam リストに登録されること。webhook URLが漏れると任意ペイロード送信されること (Slack等)。redirect URL の宛先を SaaS 側が任意 URL に書き換えられる仕様だと、オープンリダイレクト攻撃の踏み台になり得ます。
対処は、メアド (to_email 等) はSaaS管理画面側で設定し、hidden inputに書かない。webhook URLは絶対にクライアントに出さない (サーバーサイドプロキシ経由)。redirect はSaaS側allowlistで宛先を制限し、任意URLに書き換えられないようにします。
Web3Formsの場合、access_key を hidden に置き、to_email や webhook は dashboard 側で設定する設計が標準。これに従えば内部情報は漏れません。
3パターンとも単発で致命傷にはなりにくい。けれど積み上がると攻撃者の偵察コストを下げます。<meta name="generator"> はビルド成果物から削除 (1行修正)。migrate/系は本番切替後にプライベートに退避するか履歴削除。フォーム hidden input は access_key 以外を最小化し、敏感情報はSaaS dashboard 側にする。
リポジトリ衛生として習慣化しておけば、外部公開と内部運用の境界線がぶれません。