クリックジャッキングとは？
iframeとHTTPヘッダーの対策を体系的に理解する

1. どんなときに被害が起きる？ 日常の画面で考える

ネット通販サイトの住所変更画面、SNSの公開範囲設定、企業の管理画面など、ログイン済みならボタン一つで操作できるページが標的になることがあります。攻撃者は、自分のページに本来のページを読み込み、透明にしたうえでユーザーが押したくなる場所へ重ねます。

2. Webページの基本：HTML・iframe・CSSの役割

HTMLは文章やボタンなどの構造を記述し、CSSは位置・色・透明度を指定します。iframe（インラインフレーム）は別のWebページを現在のページ内に表示する要素です。たとえばブログに地図や動画プレイヤーを埋め込むときにも使われます。

<!-- 正当なiframeの例：地図などを自分のページ内に表示 -->
<iframe src="https://maps.example.test/embed"
        title="アクセスマップ"></iframe>

iframeには独立したページが読み込まれます。攻撃者が別サイトのページを重ねようとしても、対象ページが埋め込みを拒否するレスポンスヘッダーを返せば、対応ブラウザは表示を拒否します。

3. 攻撃はどう成立する？ ノード図で3者を理解

攻撃では透明化のためにCSSのopacity（不透明度）や位置指定が悪用されます。たとえば前面の透明フレームと背面の『抽選ボタン』を重ねると、見た目のボタンと実際にクリックを受けるページが一致しません。

4. オリジンとは？ URLのどこが同じなら『同一』か

Origin（オリジン）は、URLのスキーム（httpsなど）・ホスト名・ポート番号の組です。たとえばhttps://account.example.testとhttps://shop.example.testは、同じ組織のドメイン配下でも別オリジンです。

後述するSAMEORIGINやCSPの'self'を理解するときの土台です。CookieのSameSiteは同一オリジンとは異なる『サイト』の概念に基づいて判定するので、名前が似ていても混同しないでください。

5. X-Frame-Options：埋め込みを拒否するHTTPレスポンスヘッダー

X-Frame-Options（XFO）は、ページを他のページのフレーム内に表示させてよいかを、子ページ自身がブラウザへ伝えるHTTPレスポンスヘッダーです。攻撃者側のHTMLを書き換えるのではなく、守る側のサーバーから返すことがポイントです。

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Frame-Options: DENY

6. 現代的な対策：CSPのframe-ancestors

CSP（Content Security Policy：コンテンツセキュリティポリシー）は、ブラウザにコンテンツの読み込み・埋め込みの制限を伝えるセキュリティポリシーです。frame-ancestorsディレクティブは、『このページを誰が埋め込んでよいか』を指定します。

# 一切のフレーム埋め込みを拒否
Content-Security-Policy: frame-ancestors 'none';

# 同一オリジンのみ許可
Content-Security-Policy: frame-ancestors 'self';

# 自社と明示的に許した提携先のみ許可
Content-Security-Policy: frame-ancestors 'self' https://partner.example.test;

対応ブラウザでは、強制適用のCSPにframe-ancestorsが含まれるとX-Frame-Optionsより優先されます。frame-ancestorsもHTTPレスポンスヘッダーで設定します。CSPの<meta>では有効にできません。

7. Cookie・HttpOnly・Secure・SameSite・HSTSを混同しない

Webセキュリティの設定は、名前が似ていても守る対象が違います。個々の対策がクリックジャッキングを直接防ぐか、それとも別の被害を減らすかを区別しましょう。

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none';

8. 操作ラボ：設定を変えると表示可能な親ページは変わる

埋め込み元が攻撃者・同一オリジン・提携先の場合を切り替えます。クリックの重なりを模式的に表示しながら、XFOとCSPのルールがどこまで許可するかを確認してください。

9. サーバー実装ではどこに設定する？

Next.jsなどで保護する場合、対象ルートのHTTPレスポンスヘッダーとして設定します。アプリの中に埋め込みが必要なページがある場合は、全ページで一律にDENYする前に要件を整理しましょう。

// next.config.ts の例（用途に合わせてパスや値を調整）
import type { NextConfig } from "next";
const nextConfig: NextConfig = {
  async headers() {
    return [{
      source: "/(.*)",
      headers: [
        { key: "X-Frame-Options", value: "DENY" },
        { key: "Content-Security-Policy", value: "frame-ancestors 'none';" },
      ],
    }];
  },
};
export default nextConfig;

これは必要最小限の概念例です。既存のCSPヘッダーがあるサイトでは、既存ポリシーを置き換えて他の制限を消さないようにframe-ancestorsを統合してください。CDNやリバースプロキシがヘッダーを追加・変更する構成では、実際の公開レスポンスを確認します。

# レスポンスヘッダー確認例
curl -I https://account.example.test/settings

# 確認したい項目
# X-Frame-Options: DENY
# Content-Security-Policy: frame-ancestors 'none';

10. XSS・CSRF・フィッシングとの違い

クリックジャッキングとCSRFは、ともに「利用者が望まない操作」の問題ですが、前者は画面上のクリック誘導が中心です。フレーム禁止だけではCSRF全般は防げませんし、CSRFトークンを使っていても、正規ページの操作をクリックさせる攻撃には別の防御が必要です。

11. 運用チェックリストと限界

• 重要な操作画面・管理画面に、原則としてframe-ancestors 'none'などの明示的な制限を設定する。
• 埋め込みが必要な画面は親ページを列挙し、最小限の許可元だけを指定する。
• HTTPレスポンスヘッダーを確認し、実際に別オリジンからのiframe表示が拒否されるかテストする。
• CookieにSecure、HttpOnly、適切なSameSiteを設定し、多層防御にする。
• 高リスク操作には、対象内容の再確認、再認証、サーバー側の厳格な認可を用意する。
• iframe以外のUI誘導や別ウィンドウを使う手口もあるため、フレーム制限だけを万能と考えない。

12. よくある疑問

参考資料・仕様

実装時はブラウザ仕様とOWASPの推奨を確認してください。特にCSPとX-Frame-Optionsの優先関係、SameSiteの制約、非対応の旧指定に注意が必要です。

• Clickjacking Defense Cheat Sheet（OWASP）
• X-Frame-Options header（MDN Web Docs）
• CSP frame-ancestors（MDN Web Docs）
• Set-Cookie header（MDN Web Docs）
• Strict-Transport-Security header（MDN Web Docs）
• Content Security Policy Cheat Sheet（OWASP）