速報

X.Orgのクライアントライブラリーで17件を修正!Linux端末と画像処理の利用範囲を点検

CATEGORY

クリックジャッキングを防ぐには?埋め込み制限と正規の連携を両立する

※本ページのリンクにはプロモーションが含まれています。

外部ページへの画面埋め込みを制限し操作の誘導を防ぐ茶色背景の概念イラスト

目次

利用者が押したのは無害なボタンのつもりでも、実際には重ねられた正規の画面を操作していた。クリックジャッキングは、偽のAPIを用意するだけでなく、本物の画面を別の文脈へ置いて利用者の意思を取り違えさせる問題です。正規の画面だから安心とは限りません。

本記事は2026年10月18日にOWASPとMDNの一次資料を確認した実務解説です。特定の新規事件の速報ではありません。管理画面とパートナー連携は仮想例で、分類、設定の選び方、試験手順は本サイトの提案です。CSP全体の導入を扱う既存記事とは分け、画面をどこへ埋め込ませるかに焦点を当てます。

スポンサーリンク

本物の画面で操作させる問題を考える

画面をiframeなどで埋め込み、その見せ方を変えると、利用者が操作の意味を正しく認識できない場合があります。攻撃の成立条件は、ブラウザーの認証状態、Cookieの送信条件、画面の構成、埋め込みの可否などによって変わります。

ログイン済みでなければ重要な操作ができないとしても、ログイン済みの本人が誘導される場面を考える必要があります。画面上のボタンを隠すだけ、難しいURLへ置くことだけを、防御の中心にはしません。

一方で、iframeを使う機能がすべて危険なわけではありません。公開ウィジェットや正規の連携は必要な場合があります。機微な操作画面と、外部へ見せるための表示専用の画面を同じ方針で扱わないことが出発点です。

出典:OWASP Clickjacking Defense Cheat Sheet。

frame-ancestorsとframe-srcは向きが違う

CSPのframe-ancestorsは、その応答のページを埋め込める親や祖先の範囲を制御します。自分のページがどこから埋め込まれてよいかを決める指定です。一方、frame-srcは自分のページから読み込むフレームの取得元に関わります。

そのため、frame-srcで外部を制限したことを、自分の管理画面を外部へ埋め込めない証拠にしないでください。守りたい応答へ適切な埋め込みの方針が付いているかを確認します。default-srcの設定だけでframe-ancestorsも指定済みだと考えないようにします。

MDNは、frame-ancestorsが入れ子の各祖先を確認することを説明しています。直接の親だけが許可されても、その上の祖先が条件を満たさなければ影響を受けます。パートナーが別のポータルへ埋め込む構成も、実際の経路で調べてください。

スポンサーリンク

HTTP応答で埋め込み方針を届ける

OWASPは、frame-ancestorsやX-Frame-OptionsをHTTPの応答ヘッダーで適用することを説明しています。HTMLのmetaタグへ同じような値を書いても、これらの制御を置き換えられません。アプリのテンプレートだけでなく、実際の応答を確認する必要があります。

埋め込みを一切認めない管理画面なら、frame-ancestorsのnoneが候補です。同一オリジンの埋め込みを必要とする画面なら、その要件に合わせて判断します。設定文字列をコピペする前に、どのページに正規の埋め込みが必要かを一覧にします。

CDNやリバースプロキシがヘッダーを消したり、別の設定を追加したりする場合もあります。開発サーバーで見た値だけで本番の状態を判断せず、利用者が受け取る応答を対象にします。

X-Frame-Optionsとの互換性を整理する

X-Frame-OptionsにはDENYやSAMEORIGINなどの指定があります。現在のブラウザーで使うCSPの方針と、必要な互換性を踏まえて設定します。複数の設定が異なる許可を表している場合は、対象ブラウザーで正規の動作を確認してください。

古いALLOW-FROMの書き方を、複数の外部パートナーを確実に許可する手段として使わないようにします。提供するブラウザーの範囲と、現行の仕様に沿って方法を選びます。

方針を複数の部署が追加する構成では、どこが最終的な設定の責任を持つかを決めます。フロントエンド、アプリ、CDNが別々に調整し、なぜ特定の連携だけ止まるのか分からない状態を避けます。

関連する公式仕様:MDN CSP frame-ancestors。

スポンサーリンク

パートナーに許可する画面は用途を狭くする

仮想の分析サービスで、パートナーのポータルへ集計の表示を埋め込みたいとします。そのために、アカウント管理や支払い変更の画面まで同じ埋め込み許可を与える必要があるかを考えます。表示専用の入口へ分ければ、外部の文脈で操作される範囲を減らせます。

許可するオリジンは、実際に必要なスキーム、ホスト、ポートを確認して限定します。広いワイルドカードを加える前に、パートナー側の別サブドメインや第三者コンテンツも同じ信頼に含めてよいかを判断します。

許可した親ページが安全であることを、このヘッダーだけで保証できるわけではありません。連携先の管理と変更通知も必要です。使わなくなったパートナーの許可は、契約終了やURL変更に合わせて取り除きます。

Cookie・CSRF・認可は別の層として残す

SameSiteなどのCookie属性は、埋め込み時に認証情報が送られる条件へ関わります。ただし、それだけを完全なクリックジャッキング対策として扱うべきではありません。画面の性質と正規の利用経路を確認し、埋め込みの方針を別に設定します。

CSRF対策も、本人の意思をすべて保証する機能ではありません。正規の画面を操作する経路では、その画面が持つトークンが使われる場合があります。認証やトークンが正しいことと、意図した文脈で利用者が操作していることを分けます。

影響の大きい操作には、対象と内容を明示した確認や必要な再認証など、業務に合う追加の条件を検討します。これらは埋め込み制限の代わりではなく、操作の間違いと不正な誘導の影響を減らす別の設計です。

JavaScriptだけのフレーム対策へ頼らない

JavaScriptで親フレームを調べて移動させる方式は、環境や制限の影響を受けます。OWASPは、フレームを使う攻撃への防御として、適切な応答ヘッダーを中心に扱っています。スクリプトが動くことだけを前提にした仕組みを、唯一の保護にしないでください。

埋め込む側でsandboxを付けることも、自分のページが他人から埋め込まれる場合の方針とは別です。親として子へ与える自由度と、子としてどの親を許すかの両方向を区別すると、設定の目的が明確になります。

一時的な不具合を直すために保護を外す場合は、対象と期間を絞ります。問題のある一画面のために全サイトの埋め込みを許すのではなく、正規の連携に必要な条件を調べて調整します。

正規の連携と拒否する埋め込みを対にして試す

自分の管理する検証環境に、許可された親ページと許可されていない親ページを用意します。画面を直接開いた正常動作、正規の埋め込み、拒否すべき埋め込みを分けて試します。重要な更新はテスト用のデータに限定します。

実際の応答ヘッダー、ブラウザーのエラー、表示の結果を対応させます。許可していないページから表示できないことと、正規の連携が使えることを両方確認します。入れ子を使う場合は、親だけでなく祖先の条件も試します。

Report-Onlyでの観測と、強制するポリシーを区別します。警告が記録されたことを遮断が成功した証拠にしないようにします。観測から強制へ移る条件と、障害時に戻す検証済みの設定を用意してください。

対象埋め込みの要件検証する条件
管理画面原則として外部へ許可しない直接表示は可能で外部埋め込みは拒否
表示専用ウィジェット必要な範囲で許可する個人情報や変更機能を含めない
パートナー連携既知のオリジンへ限定する正規経路と無関係の親を区別
入れ子のフレーム祖先全体を確認する一部だけ許可された構成を試す

スポンサーリンク

同じ画面の二つの用途を分ける判断

仮想の顧客ポータルで、外部のダッシュボードには契約状況だけを見せたい一方、本人用の画面には変更ボタンがあるとします。両方を同じHTMLで提供し、親のURLを見てボタンを消すだけでは、保存処理の権限まで分かれません。表示専用の入口と変更を受け付ける入口を分け、サーバー側の条件も対応させます。

埋め込みを許可する画面へ後から機能を追加する場合も、元の許可がその操作へ適切かを確認します。外部へ見せるために作ったページが、いつの間にか認証手段や連絡先を変えられる画面になっていないかを見ます。

判断の記録には、なぜその親を許可したかと、許可される機能を残します。別部署が追加した機能にも方針が引き継がれ、例外だけが増えないようにします。

ヘッダーの有無より適用する範囲を確認する

点検ツールがヘッダーを見つけても、重要な画面のすべてへ適用されているとは限りません。ログイン画面、設定変更、エラー画面、別ホストで提供する管理機能も対象へ含めます。ヘッダーが付くURL一つだけで合格としないことが重要です。

新しい埋め込み連携を導入する際は、使う画面、許可する親、扱う情報、契約終了時の削除を一緒に確認します。例外が増えたら、ページの役割を分ける設計へ戻ることも検討します。

クリックジャッキング対策は、すべてのフレームを無差別に止める作業ではありません。重要な操作を意図しない文脈へ置かせず、必要な連携には限定した入口を用意し、ブラウザーでその境界を確認できる運用にすることです。

スポンサーリンク

参考資料

以下は2026年10月18日に直接確認した一次資料です。製品やサービスの設定は、実際に利用する版と環境に対応する資料で確認してください。

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、これまでに100以上のWordPressサイトの構築・保守を担当してきました。Webサイト制作に加え、アプリ開発やAIを活用した開発にも取り組み、近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
WordPress / PHP / JavaScript / アプリ開発 / Webサイトの運用・セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

スポンサーリンク

関連する記事

おすすめの書籍