[13] HTTP の X-Frame-Options: ヘッダーは、そのHTTP応答に含まれる文書をフレームにより埋め込んで表示して良いかどうかを表します。 主としてクリックジャッキング対策のために使われます。

[44] このヘッダーは CSP frame-ancestors 指令により廃止されました >>43。 しかし現在でも複雑な CSP よりも単純な X-Frame-Options: が好まれることがあります。

仕様書

用法

[16] HTML では iframe 要素などによってある文書の中に他の文書を埋め込むことができますが、 これを悪用し、利用者が気づかない内に埋め込まれた文書内をクリックさせ、 利用者が意図しない動作を引き起こさせる「クリックジャッキング」攻撃があります。 これを防ぐため、自身を他のサイトに埋め込んで表示することを拒む X-Frame-Options: ヘッダーを指定することができます。

値

[19] 値としては、次の3種類のいずれか1つを指定できます >>12。これらは大文字・小文字不区別です >>12。

  1. |
    1. DENY
    2. SAMEORIGIN
    3. ALLOW-ORIGIN ...

[20] DENY の場合、フレーム内に表示してはなりません >>12。

[21] SAMEORIGIN の場合、異なる起源のページのフレーム内に表示してはなりません >>12。起源が同じか判断できなければ、 DENY のように扱わなければなりません >>12。

[22] 起源が同じか判定できないとはどのような場合なのでしょうか・・・。

[23] 同じ起源かどうかの判定の対象がフレームを含むページであるWebブラウザーと、 最上位閲覧文脈であるWebブラウザーや、先祖閲覧文脈すべてのWebブラウザーがあります >>12。

[24] 現状違っているのは仕方ないとして、どちらであるべきなのかは定義されていません。 それを決めるのが仕様書の役割だと思うのですが・・・。

[25] ALLOW-ORIGIN の後にスペースが続き、その後に serialized-origin (妥当な起源) が続く場合、最上位閲覧文脈が指定された起源でなければ、表示してはなりません >>12。

  1. ALLOW-ORIGIN
  2. SP
  3. 起源のASCII直列化

[26] 「ドメインアドレスより後のデータ (/ より後のデータ) は無視される >>12」とあります。 起源だけでなく URL path が指定されていた場合ということなのでしょうか。意図が不明瞭です。

[33] ALLOW-ORIGIN は IE 拡張で、他の Webブラウザーは実装していないことがあります >>12。[39] CSP の frame-ancestors は、先祖すべての閲覧文脈と比較することになっています >>38。

[27] 起源の比較は RFC 6454 に従い行うべきです >>12。 しかし既存の実装はポートの違いを無視しています >>12。

[28] なぜ必須ではなく推奨なのでしょうか。また、ポートを無視するという情報は有用ですが、 であるから互換性のためにそれに倣うべきなのか (それなら推奨と矛盾してしまいますが...)、 それともポートを無視しないようにしていくべきなのか。標準化を通して相互運用性を向上させようという意欲が感じられません・・・。

[29] ここでいうスペースは、1文字以上の SP や HTAB ですが、1文字の SP とするべきです >>12。また解釈前や下流への転送前に1文字の SP にまとめるか、 SP に置き換えるべきです >>12。

適用対象

[30] フレームの表示には例えば次のものが含まれます: iframe, frame, object, embed, applet >>12。 プラグイン内の表示も含まれます >>12。

[31] HTML の表示が対象 >>12 と書かれていますが、 XML など他のものも対象となっているはずです (そうでないと意味がありません)。

[42] 表示は行われませんが、 HTTP 層の処理は行われます。例えば Set-Cookie: ヘッダーがあれば、その処理は通常通り行われます。

処理モデル

[32] フレームの表示が禁止されていれば、ただちにダウンロードや構文解析を中止abortして構いません。 ブラウザーはできるだけすぐに「フレームなし」ページにリダイレクトするべきです。 そのページには URL を表示したり、新しい窓で開くオプションを提示したりできます。 実装によっては空のフレームを表示するだけだったりします。 >>12

[40] CSP の frame-ancestors が指定されていれば、そちらが優先されるべきです。 X-Frame-Options は無視されるべきです。 >>38

[41] なぜ必須ではなく推奨なのか謎です。動作が実装ごとに異なっていてはセキュリティーホールになりかねないと思いますが。

キャッシュ

[34] X-Frame-Options のキャッシュは推奨されません。現状どのWebブラウザーもキャッシュしていません。 >>12

[35] サーバーは要求元 (の Origin: など) を見て X-Frame-Options: を変えることがあるので、キャッシュするべきではありません >>12。

[36] しかし X-Frame-Options: だけキャッシュしないわけにもいかないので、 安全側に倒すと、応答全体がキャッシュできないのですかね?

実装

歴史

IE8

[14] 2009年に IE8 が初めて実装しました。

  • [2] IEBlog : IE8 Security Part VII: ClickJacking Defenses ( 版) http://blogs.msdn.com/ie/archive/2009/01/27/ie8-security-part-vii-clickjacking-defenses.aspx
  • [3] Combating ClickJacking With X-Frame-Options - IEInternals - Site Home - MSDN Blogs ( 版) http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

追随

[15] IE 以外の Webブラウザーもすぐに追随して実装しました。

  • [6] 690168 – Implement Allow-From syntax for X-Frame-Options ( 版) https://bugzilla.mozilla.org/show_bug.cgi?id=690168
  • [5] Bug 94836 – Support for X-Frame-Options: Allow-From [uri] ( 版) https://bugs.webkit.org/show_bug.cgi?id=94836

標準化

  • [8] draft-ietf-websec-frame-options-00 - HTTP Header Frame Options ( ( 版)) http://tools.ietf.org/html/draft-ietf-websec-frame-options-00
  • [4] draft-ietf-websec-x-frame-options-01 - HTTP Header X-Frame-Options ( 版) http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01

[7] 初期案では Frame-Options:, Frame-Option: といった名前でしたが、その後実際に使われている X-Frame-Options: に変更されています。

[9] ( ( 版)) http://seclab.stanford.edu/websec/framebusting/framebust.pdf

[10] Coordinating Frame-Options and CSP UI Safety directives ( (Hill, Brad 著, 版)) http://lists.w3.org/Archives/Public/public-webappsec/2012Jul/0014.html

[17] RFC 7034 は、 RFC 6648 で X-* が非推奨とされていることを理由に CSP に置き換えられる >>12 と述べています。

[18] RFC 7034 は既に X-* の名前が使われているものを破棄させることを意図してはいないと思うのですが・・・。

[37] RFC 7034 は2013年に発行された比較的新しい仕様書でありながら、 CSP に移行するべきという理由で細部を明確に規定しておらず、 fetch や navigate のような近代的な用語を用いておらず、 browsing context もほとんど言及がない前近代的な文書となっています。

[11] IRC logs: freenode / #whatwg / 20130717 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20130717#l-203

[45] IRC logs: freenode / #whatwg / 20151002 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20151002

[46] User Interface Security and the Visibility API ( 版) https://w3c.github.io/webappsec-uisecurity/

[48] CSP2 には CSP frame-ancestors と X-Frame-Options: との関係が一応規定されていました >>47 が、 CSP と Fetch の関係を明確化した CSP3 では当該部分が削除されています >>49。 従って現状 X-Frame-Options: を処理するべき正確なタイミングはどこでも規定されていません。

  • [47] Content Security Policy Level 2 ( 版) https://w3c.github.io/webappsec-csp/2/#frame-ancestors-and-frame-options
  • [49] Content Security Policy: Document Features ( 版) https://w3c.github.io/webappsec-csp/document/

[50] Issue 610284 - chromium - Regression: 'Download as PDF' option is not working on 'www.chromium.org/Home'. - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=610284

[51] クリックジャッキング防止のために無条件で本ヘッダーを指定するようなサーバーもあるようですが、 本当に指定する必要があるのかどうかはケースバイケースです。よく検討する必要がありそうです。

[52] 'frame-ancestors' obsoletes 'X-Frame-Options' (mikewest著, ) https://github.com/w3c/webappsec-csp/commit/2831e21665d4c2d0dc577b63736d271f1339f08c

[53] Fix X-Frame-Options issue link (annevk著, ) https://github.com/whatwg/html/commit/ede1de13e9aa97b3bfeb958ad59705160e4976c9

[54] Fix X-Frame-Options issue link by annevk · Pull Request #3258 · whatwg/html () https://github.com/whatwg/html/pull/3258

[55] Consider making `X-Frame-Options: deny` to create a new browsing context group · Issue #4218 · whatwg/html · GitHub () https://github.com/whatwg/html/issues/4218

[56] Consider making `X-Frame-Options: deny` to create a new browsing context group · Issue #4218 · whatwg/html () https://github.com/whatwg/html/issues/4218

[57] X-Frame-Options - HTTP | MDN (, ) https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options