セキュリティ

source mapの露出を含むHTMLを共有するときのリスクと対策

Reactアプリやバンドルされたアプリケーションをビルドした際に生成されるソースマップは、開発者にとって便利なデバッグツールですが、外部に公開されると重大なソースコード漏えいにつながります。本記事では、ソースマップ露出のビジネスリスクを具体的に説明し、除去・制限・監視の3段階の対策を実務的に解説します。

なぜ危ないのか

ソースマップが有効な状態で本番サイトを公開すると、ブラウザのDevTools(Sourcesタブ)から元のソースコードを完全に閲覧できます。minifyやobfuscationによる難読化が完全に無効化されます。コードの中にコメントで記載した設計判断やAPIエンドポイントのURL、認証ロジックの詳細が全て見える状態になります。

ソースマップの存在は攻撃者にとって有利な足がかりとなります。アプリケーションの内部構造を把握することで、SQLインジェクションやXSSなどの脆弱性の探索効率が大幅に上がります。ソースマップが公開されていた実際のインシデントでは、元のコードに残っていたAPIキーがそのまま読み取られたケースが報告されています。

  • 相手がログインなしで開ける状態か確認する
  • PCとスマホで最低1回ずつ表示を確認する
  • 内部情報・個人情報・不要な外部送信が残っていないか見る
  • レビュー期限と修正時の差し替え方を決めておく

ソースで見る場所

公開済みのサイトをチェックする場合は、ブラウザのDevToolsを開きSourcesタブを確認してください。左パネルにソースファイルのツリーが展開され、元のファイル名(App.tsx、index.jsなど)が表示されていれば、ソースマップが機能している状態です。minifyされたファイル名のみが表示されていれば、ソースマップは無効化されています。

サーバー側での確認は`curl -I https://your-site.com/static/js/main.chunk.js.map`を実行してください。200 OKが返れば`.map`ファイルが公開されています。403や404が返れば公開されていません。全ての`.map`ファイルに対して同様の確認を行い、少なくとも一つでもアクセス可能なものがあれば対応が必要です。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

安全に共有する設定

社外共有用HTMLとしてビルドする場合は、本番ビルドと同じソースマップ無効化設定を適用してください。Viteであれば`build.sourcemap: false`、webpack/CRAであれば`GENERATE_SOURCEMAP=false`を環境変数で設定します。レビュー共有用ビルドのために別の`.env.review`ファイルを作り、CI/CDのレビュービルドジョブで使用する設定にすると管理が楽になります。

ギガサイト便でファイルをアップロードする際は、ビルド成果物のうち`dist/`または`build/`ディレクトリの中から`.html`と`.css`、`.js`のみを選択してアップロードしてください。`.map`ファイルはアップロード対象から除外することを共有フローのルールとして明文化してください。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

再発防止ルール

本番・外部共有向けのビルドコマンドを`Makefile`またはpackage.jsonのscriptsに定義し、そのコマンド内でソースマップ無効化が保証されるようにしてください。`build:external`という専用スクリプトで`GENERATE_SOURCEMAP=false react-scripts build`を実行する設計にすれば、担当者が設定を意識しなくてもソースマップが含まれない成果物を得られます。

定期的な監視として月1回、公開サイトのDevToolsを開いてSourcesタブを確認する時間を設けてください。設定変更やライブラリのアップデートによって意図せずソースマップが有効になるケースがあります。自動化するならLighthouseのCIプラグインを使ったチェックや、自作のcurlスクリプトをCronで定期実行する方法が有効です。

  • HTML内の外部script・form action・iframeを確認する
  • APIキーやトークンらしき文字列がないか検索する
  • 画像・CSS・JSのパスが公開後も解決できるか見る
  • noindexと認証を混同せず、必要なら両方設定する

よくある質問

ソースマップを削除するとバグ発生時の原因調査が困難になりますか?

Sentryなどのエラートラッキングサービスにビルド時にソースマップをアップロードすれば、本番環境にファイルを置かずにスタックトレースを元のコードで確認できます。SentryはCI/CDとの統合が簡単で、デプロイのたびに自動アップロードする設定が公式ドキュメントに詳しく記載されています。

Cloudflare PagesやVercelでホスティングする場合もソースマップが公開される可能性はありますか?

ビルド設定でソースマップ生成を無効化していれば、ホスティング環境に関係なく`.map`ファイルは生成されません。ただしプラットフォーム側の設定でビルドオプションが上書きされることがあるため、デプロイ後にDevToolsで実際にSourcesタブを確認することが重要です。

すでにソースマップが公開されてしまっている場合、優先して対処すべきことは何ですか?

まずソースマップを無効化したビルドで即時デプロイしてください。次にソースマップから読み取れるコードにAPIキーやシークレットがハードコードされていなかったか確認し、もし含まれていた場合は該当のキーを即座にローテーションしてください。アクセスログを確認してソースマップに対するアクセスがあったかも調査します。

関連記事

セキュリティ

http混在を含むHTMLを共有するときのリスクと対策

http混在を含むHTMLを共有した場合のリスクを把握し、適切な対処法を選びたい方向け。ブラウザによる表示ブロックや通信傍受のリスクを具体的に示しながら、修正・代替策・共有設定の3つの観点から対策を解説します。

5分で読める
セキュリティ

XSSを含むHTMLを共有するときのリスクと対策

XSSが含まれる可能性のあるHTMLを共有するリスクを把握し、適切な対策を講じたい担当者向け。被害シナリオ、コードレベルの修正方法、CSPによる軽減策、再発防止の仕組みづくりを段階的に解説します。

5分で読める
セキュリティ

オープンリダイレクトを含むHTMLを共有するときのリスクと対策

オープンリダイレクトを含むHTMLを外部共有するリスクを理解し、修正判断と対策を迷わず行いたいチームリーダー・開発者向け。フィッシング被害の具体的なシナリオと、許可リスト実装・URL認証による二段階対策を解説する。

6分で読める
「セキュリティ」の記事をもっと見る →