なぜ危ないのか
社内ドメイン名はそれ自体が情報資産です。`api.hr.example.co.jp`のようなサブドメインが外部に露出すると、「この会社はHRシステムをサブドメインで分離して運用している」という内部構造情報が漏れます。標的型攻撃では、こうした情報が攻撃者の偵察フェーズで使われます。
外部公開したHTMLにクローラーがアクセスしてリンクを辿ろうとした場合、社内ドメインへのリクエストが発生します。VPNなしではアクセスできない設計であっても、タイムアウトまでのレスポンスから「内部サーバーが存在すること」が推測できます。また、共有を受けた相手が悪意を持っていた場合、URLをフィッシングメールの誘導先として悪用するリスクもあります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
リスクのある記述はHTMLの複数箇所に潜みます。`<a href>`のリンク先、`<form action>`の送信先、`<img src>`の画像パス、`<link href>`のスタイルシートパス、そして`<script>`内のAPI URLが主な確認ポイントです。特に開発時に使ったAPIのベースURLが定数として残っているケースは見落としやすいです。
CSSファイルもチェック対象です。`background-image: url('https://cdn.internal.example.co.jp/...')`のような記述が外部CSSに含まれていると、HTMLを見ただけでは気づけません。HTMLと一緒に渡すCSSやJSファイルも同様にgrepで確認してください。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
社内ドメインを全て除去または置換した後は、共有方法にも注意が必要です。Slackのパブリックチャンネルへのファイル投稿や、アクセス制限なしのクラウドストレージリンクは避けてください。ギガサイト便のようにアクセスログが記録され、誰がいつ閲覧したかを把握できるサービスを使うと、後からトレースが可能になります。
共有先が複数の会社にまたがる場合は、URLを1つ発行して全員に配布するのではなく、会社ごとに個別URLを発行することを検討してください。ギガサイト便の会社ドメイン認証を使えば、`@partnerA.co.jp`のみアクセスできるURLと`@partnerB.co.jp`のみアクセスできるURLを別々に設定できます。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
HTMLを外部共有する前の必須確認事項として「社内ドメインリスト」を作成し、チェックスクリプトに組み込んでください。自社が使用している内部ドメインを列挙したファイル（例：`.internal-domains`）をリポジトリに置き、grepで一括検索できるようにすると手間が減ります。
IncidentレポートにHTML共有起因の情報漏えい事案が記録されているチームは、共有ワークフローそのものを見直す時期です。「作ったらSlackで送る」という慣行を「作ったらスキャンしてURLで共有する」に置き換えるだけで、多くのリスクを排除できます。変更は小さく始めて、まず1チームで試してから横展開するのがスムーズです。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
社内ドメインが含まれていたことを共有後に発見した場合、最初にすべきことは何ですか？
共有URLを即座に無効化してください。URLベースの共有であれば削除で対応できますが、ファイルを直接添付した場合は相手に削除を依頼する必要があります。その後、アクセスログを確認して誰がダウンロードまたは閲覧したかを把握し、インシデントレポートを作成します。
社内ドメインをプレースホルダーに置換する際に、どんな文字列を使えばよいですか？
example.comやlocalhost等の明確に内部専用と分かる文字列が安全です。実在するドメインに置換すると、そのドメインへ意図しないリクエストが飛ぶため避けてください。開発用途であれば`#INTERNAL_API_URL`のようなプレースホルダー形式で残すとレビュワーが気づきやすくなります。
制作会社に渡すHTMLには必ず社内ドメインを除去すべきですか？
秘密保持契約（NDA）を締結している制作会社であっても、不要な内部情報は除去して渡すことがセキュリティのベストプラクティスです。制作会社のシステムが侵害された場合、そこに保存されたHTMLから自社の内部情報が漏れるリスクがあります。