外部サービスが攻撃されたら自社サイトはどうなる？4つの型で整理

Webサイトは、自社のサーバーだけで完結しているわけではありません。Googleマップ、Webフォント、アクセス解析タグ——ページを1つ開くだけで、複数の外部サービスとの通信が発生しています。では、それらの外部サービスが攻撃を受けたら、自社サイトはどうなるのでしょうか。

先日、クライアントからまさにこの質問をいただく機会があり、改めて整理しました。結論から言うと、判断基準は意外なほどシンプルです。リスクを分けるのは、サービスの提供元がどこかではなく、「どの方式で読み込んでいるか」です。

同じGoogle製のサービスでも、Googleマップとタグマネージャーではリスクの性質がまったく違います。この記事では、外部サービスの読み込み方式を4つの型に分類し、それぞれ「攻撃を受けたとき自社サイトに何が起きうるか」を、発注側の担当者がベンダーの説明を評価できるレベルまで整理します。

外部ドメインを洗い出したら60以上あった

整理のきっかけとして、あるサイトのソースコードから外部ドメインへの参照をすべて洗い出してみました。やり方自体は難しくありません。HTMLソースに含まれるsrc属性・href属性のURLを抽出し、自社以外のドメインを集計するだけです。

結果は60ドメイン以上。数字だけ見ると不安になりますが、仕分けてみると実質は5系統のサービスに集約され、読み込み方式は次の4つの型に分類できました。私たちENVY DESIGNでも、他社で制作されたサイトの保守・更新を引き継ぐ際は、まずこの棚卸しから始めます。

先に4つの型の全体像を表にまとめます。下に行くほど自社ページとの結びつきが強く、注意が必要になります。

型	読み込み方	代表例	提供元が攻撃された場合の影響
リンク型	<a href>	提携先・グループ会社へのリンク	影響なし（通信自体が発生しない）
iframe型	<iframe>	Googleマップの埋め込み	ブラウザが隔離（ページ内容へのアクセスを遮断）
CSS型	<link rel='stylesheet'>	Webフォントサービス	表示の崩れまで（プログラムを実行できない）
script型	<script src>	アクセス解析タグ・JSライブラリ	自社ページ内でコードが実行されうる（対策が必要）

それでは、分離が強い順に1つずつ見ていきます。

型1：リンク型——そもそも「読み込んで」いない

<a href>タグで外部サイトへのリンクを張っているだけのパターンです。提携先の紹介や、グループ会社の申し込みフォームへの誘導などがこれにあたります。

洗い出した60以上の外部ドメインのうち、大半はこのリンク型でした。リンクは、ユーザーがクリックするまで通信が一切発生しません。クリック後はユーザーが相手のサイトに「移動」するのであって、自社サイトのページはもう画面に存在しません。

仮にリンク先のサービスが攻撃を受けても、影響はリンク先のシステム内で完結します。リンク先のフォームで入力されたデータも相手側のサーバーに直接送信されるため、自社サイトに波及する経路そのものがありません。

型2：iframe型——表示はするが、隔離されている

<iframe>タグで外部サービスの画面を自社ページ内に埋め込むパターンです。代表例がGoogleマップの埋め込みで、アクセスページや店舗案内でほとんどのサイトが使っています。

見た目には自社ページの一部に見えますが、ブラウザの内部では、自社ページとiframe内のコンテンツは別々のページとして扱われます。そして、すべてのブラウザに標準搭載されている同一オリジンポリシーというセキュリティ機構により、ドメインの異なるページ同士は互いの内容にアクセスできません。

つまり、仮にiframe内のサービスに悪意あるコードが入り込んでも、そのコードが自社ページのHTML・入力値・Cookieに手を伸ばそうとした瞬間、ブラウザが遮断します。「表示はさせるが、境界をまたいだデータアクセスはさせない」——これがiframe型の構造です。

1点だけ補足すると、同一オリジンポリシーの解説記事には「iframeは制限の対象にならない」と書かれていることがあります。これは「別オリジンのコンテンツを読み込んで表示すること自体は許可されている」という意味で、表示された後の中身へのアクセスは遮断されます。表示の可否とデータアクセスの可否は別のルールで、ここを混同すると議論が噛み合わなくなるので注意が必要です。

型3：CSS型——最悪でも「見た目が崩れる」まで

<link rel='stylesheet'>で外部のCSSファイルを読み込むパターンです。代表例はWebフォントの配信サービスで、指定した書体のフォントファイルとその表示定義を外部サーバーから受け取ります。

CSSはページの見た目（色・配置・フォント）を定義するだけの言語で、プログラムを実行する能力がありません。仮に配信元が侵害されて中身が改ざんされても、起きうるのは表示の崩れや見た目の書き換えまでで、入力データを盗んだり通信を乗っ取ったりするコードは動かせません。

型4：script型——自社ページの中で、フル権限で動く

<script src>タグで外部のJavaScriptを読み込むパターンです。アクセス解析タグ（Googleタグマネージャーなど）、jQueryをはじめとするJSライブラリ、スクロール演出などの各種ライブラリがこれにあたります。

ここが4つの型の中で唯一、構造的に事情が異なります。

scriptタグで読み込まれたJavaScriptは、配信元のオリジンではなく、読み込んだ側——つまり自社ページのオリジンの権限で実行されます。ブラウザから見ると、外部から取り寄せたコードと自社のHTMLに直接書いたコードは、実行の時点で区別がつきません。

iframe型では「自社ページ」と「外部コンテンツ」という2つの領域があり、その間に同一オリジンポリシーの壁が立ちました。しかしscript型では、外部のコードが最初から自社ページの内側で動くため、壁を立てる境界そのものが存在しません。ページ内の入力値を読むことも、内容を書き換えることも、正規の権限としてできてしまいます。

仮に配信元のサーバーが乗っ取られ、改ざんされたコードが配信された場合、それを読み込んでいるすべてのサイトのページ上で、悪意あるコードがフル権限で動きうる——これがscript型固有のリスクです。自社を直接攻撃するのではなく、自社が利用している供給元を経由して間接的に攻撃する手法であることから、サプライチェーン攻撃と呼ばれます。

「どこから来たか」ではなく「どこで動くか」

ここまでの4つの型を踏まえると、冒頭の結論に戻ります。

同じGoogle製でも、Googleマップはiframe型なので隔離され、Googleタグマネージャーはscript型なので隔離されません。「Googleだから安心」でも「外部だから危険」でもなく、そのコードがどこで動くかが、リスクの濃淡を決めています。

外部サービスの安全性を議論するとき、提供元のブランドや知名度で判断してしまいがちですが、見るべきは読み込み方式です。逆に言えば、無名のサービスでもリンク型なら自社サイトへの影響経路はなく、大手のサービスでもscript型なら相応の備えが要る、ということになります。

script型は「排除」ではなく「保険をかける」対象

では、script型は使うべきではないのでしょうか。そうではありません。

解析タグやJSライブラリを外部の配信サーバー（CDN）から読み込む構成は、世界中のほぼすべてのWebサイトが採用している標準的な作りです。信頼できる大手の配信元を選んだ上で、技術的な保険をかけるのが業界標準の付き合い方です。

保険の代表がCSP（Content-Security-Policy）です。サーバーからブラウザに「このページで実行を許可するスクリプトの読み込み元は、これらのドメインだけ」と宣言する仕組みで、設定しておけば、想定外のドメインから不正なスクリプトが読み込まれそうになってもブラウザ側で実行をブロックできます。加えてSRI（Subresource Integrity）という、読み込むファイルの改ざんを検知して実行を拒否する仕組みもあります。

発注側の担当者として押さえておきたいポイントを整理すると、次の3つです。

• 新しいタグやウィジェットの設置を依頼・許可するときは、どの方式（リンク・iframe・CSS・script）で読み込まれるのかを確認する
• script型のサービスを追加するときは、配信元の信頼性と、CSPやSRIといった保険の有無をあわせて確認する
• 定期的に外部ドメインの棚卸しを行い、使っていないサービスの読み込みを削除する

棚卸しの副産物——「本当に必要か」も見えてくる

読み込み方式の整理には、セキュリティ以外の効用もあります。

冒頭の棚卸しでは、あるWebフォントサービスが、実はサイト内の電話番号の数字を表示するためだけに使われていることが分かりました。用途がそれだけなら、フォントを自社サーバーから配信する形に切り替えて、外部依存を1つ減らすという選択肢も検討できます。外部サービスは契約状況や提供元の都合で表示が変わるリスクも抱えているため、依存の棚卸しは定期的にやる価値があります。

外部依存を整理するという意味では、ドメインやサーバーといったインフラ層も同じ発想で捉えられます。インフラ側の整理についてはドメイン移管でサイトは止まる？の記事で詳しく解説しています。

外部サービスのリスクに関するよくある質問

Googleマップを埋め込んでいると、Googleが攻撃されたとき自社サイトも危険ですか？

Googleマップはiframe型のため、ブラウザの同一オリジンポリシーによって自社ページから隔離されています。仮にマップ側で問題が起きても、自社ページの内容やデータにアクセスすることはできません。ただし同じGoogle製でも、タグマネージャーのようにscript型で読み込むサービスは事情が異なります。判断は提供元ではなく読み込み方式で行ってください。

外部のJavaScriptを読み込むのは危険なのでやめるべきですか？

やめる必要はありません。解析タグやJSライブラリを外部から読み込む構成は、世界中のほぼすべてのサイトが採用している標準的な作りです。信頼できる配信元を選び、CSPやSRIといった保険をかけて付き合うのが現実的な対応です。

自社サイトがどの外部サービスを使っているか確認する方法はありますか？

ページのソースコードに含まれるsrc属性・href属性のURLから、自社以外のドメインを洗い出す方法が確実です。ブラウザの開発者ツールのネットワークタブで、ページ表示時に実際に通信が発生しているドメインを確認する方法もあります。自社での確認が難しい場合は、制作会社や保守ベンダーに棚卸しを依頼するとよいでしょう。

CSPの設定は誰に依頼すればよいですか？

CSPはWebサーバーが返すレスポンスヘッダーで設定するため、サーバーやCDNを管理している事業者（制作会社・保守ベンダー・インフラ会社）への依頼になります。設定を誤ると正常なスクリプトまで止まってしまうため、サイトで使っている外部サービスの棚卸しとセットで進めるのが安全です。

まとめ：発注側が確認すべきは「どの方式ですか」の一言

外部サービスのリスクは、提供元ではなく読み込み方式で決まります。リンク型は通信すら発生せず、iframe型はブラウザの仕組みで隔離され、CSS型は最悪でも表示崩れまで。構造的に注意が必要なのはscript型だけで、これは排除するものではなく、CSPなどの保険をかけて付き合うものです。

Web制作やセキュリティ診断の場面でベンダーから説明を受けるとき、「そのサービスはどの方式で読み込んでいますか」と一言確認できるだけで、説明の妥当性を自分の軸で評価できるようになります。発注側の担当者にとって、この4分類は覚えておいて損のない判断基準です。

関連記事: WordPressのXML-RPCとは？無効化すべき理由と実際の対応事例

ENVY DESIGNでは、500件以上のホームページ制作実績をもとに、制作だけでなく保守・運用の中で外部依存の棚卸しやセキュリティ面の整理もサポートしています。自社サイトがどんな外部サービスに依存しているか把握できていない、ベンダーの説明を評価する軸がほしい、という方はお問い合わせよりお気軽にご相談ください。