X-Frame-Optionsはiframeで見せるpageを決めてからDENYかSAMEORIGINを選ぶ

X-Frame-Optionsは、自分のpageを他のpageのframeやiframeへ表示させるかを決めるHTTP response headerです。外部siteへ埋め込ませる必要がないpageはDENYを選びます。同じoriginのpage内でだけ埋め込みたい場合はSAMEORIGINを選びます。埋込の可否を先に決めず、一律でheaderを付けると、必要な資料pageや管理画面の表示まで止めることがあります。

RFC 7034は、X-Frame-Optionsを、contentがframeまたはiframeへ埋め込まれることを防ぎ、clickjackingを抑えるためのHTTP response headerとして定義しています。値はDENY、SAMEORIGIN、ALLOW-FROMの三つです。DENYはどのframeでも表示を許可せず、SAMEORIGINはcontentと同じoriginのpageからだけ表示を許可します。ALLOW-FROMは指定した一つのoriginを許可しますが、複数domainのlistやwildcardは指定できません。

設定する対象はsite全体とは限りません。会社案内、記事、ログイン後の画面、問い合わせform、PDFを表示するpageなどで、外部の枠へ入れる必要は異なります。外部siteへ見せない方がよいpageと、取引先のportalへ表示する約束があるpageを同じ値で扱うと、どちらかの目的を損ないます。URLごとに埋込の必要性を決めることが先です。

headerを追加しても、contentの権限や入力内容まで保護するわけではありません。X-Frame-Optionsが扱うのは、pageをframeの中へ表示する経路です。formの入力検査、ログイン、HTTPS、外部scriptの読み込みなどは別の確認が必要です。securityの設定を一つ入れたことを、site全体の安全性が決まったことと混同しません。

自社pageを埋め込む必要があるかで選ぶ

headerの値は、どのpageをどこへ出すかで決めます。外部serviceのmapやmovieを自社siteへ貼る作業と、自社のpageを外部siteへ貼らせる作業は逆向きです。外部serviceを自社page内へ埋め込むだけなら、自社のresponseへX-Frame-Optionsをどう設定するかとは別に確認します。

DENYを付けたpageは、自社site内のiframeからも表示できません。社内portalやspecial pageでiframeを使う場合は、先に対象URLを一覧にします。SAMEORIGINは、同じcompany名のdomainではなく、originが同じかどうかで判断します。httpとhttps、wwwありとなし、portが違う場合を同じsiteだと思い込まないことが必要です。

URLがredirectする場合も、最初に書いたURLだけで判断しません。iframeが実際に表示しようとする最終URLと、そこで返るresponse headerを確認します。httpからhttpsへ移る、wwwの有無を統一する、ログイン画面へ移るといった経路があると、埋込を許可したいpageとheaderを付けたpageが一致しないことがあります。直接URLを開く確認と、iframeの中で開く確認を分けます。

ALLOW-FROMを検討する場合は、許可先を一つ決められるかを先に確認します。複数の取引先や複数のsubdomainへ見せたいなら、設定を継ぎ足す前に、iframeで見せる必要が本当にあるかを考えます。外部siteから直接linkしてもらう方法なら、外部の枠内へ自社pageを表示させる必要はありません。埋込という手段と、利用者を必要なpageへ案内する目的を分けます。

埋込を止める設定と画面の見た目を混同しない

clickjackingでは、利用者がvideoの再生buttonやmenuを押したつもりで、見えない広告や別の操作を押す形が問題になります。X-Frame-Optionsは、他のpageに重ねて表示される経路を制限するheaderです。buttonの色、layout、広告の配置を直す機能ではありません。

たとえば、取引先のsiteへ自社の問い合わせformをiframeで埋め込んでいる場合、DENYを付けるとformが表示されなくなります。この問題を避けるために、headerを外す前に、埋込が本当に必要かを確認します。問い合わせ用URLへ直接linkする方法、formの入力を取引先側で受ける方法、自社site内の専用pageへ移す方法もあります。必要な導線と、pageを他siteの枠内へ表示させることは別に決めます。

自社site内でiframeを使う場合も、見た目だけでSAMEORIGINを選びません。資料pageをiframeで出しているのか、別のsystemを見せているのか、古いlayoutの都合でiframeが残っているだけなのかを調べます。iframeを外して通常のpageとしてlinkできるなら、埋込を許可するURLを減らせます。設定の例外を増やす前に、利用者の導線を単純にできないか考えます。

clickjackingを心配しているpageでは、利用者が何の操作をするかも確認します。問い合わせの送信、設定変更、購入のように意図しない操作が問題になるpageと、公開済みの記事を読むだけのpageでは、影響が同じではありません。すべてを同じ危険度として扱うより、外部へ表示する必要と操作の重要度を並べて決めます。

設定前後にresponse headerと埋込先を確認する

serverまたはapplicationの設定を変更する前に、対象pageと埋込先を記録します。themeだけを直しても、X-Frame-Optionsは通常HTMLのheadではなくHTTP response headerで返ります。

1. 外部siteまたは自siteのiframeで表示している自社URLを集める。
2. URLごとに、iframe表示が必要かを決める。
3. 必要ないpageはDENY、同じorigin内だけ必要なpageはSAMEORIGINの候補にする。
4. serverまたはapplicationでresponse headerを設定する担当と変更場所を記録する。
5. browserのnetwork情報で対象URLのresponse headerを確認する。
6. 許可するiframeと、許可しない外部pageの両方で表示を確認する。

iframeを使う外部serviceの仕様は、相手側が変えられます。自社で所有していないserviceのURLを前提にheaderを決める場合は、契約先、URL、変更時の連絡先を残します。設定作業を外部へ任せても、どの自社pageを外部の枠内へ表示させるかは、自社で判断しておきます。

確認するときは、headerが返っていることだけで終えません。許可したiframeでは必要なpageが読めるか、禁止した外部pageでは表示されないか、直接開いた場合に通常どおり読めるかを試します。問い合わせformなら入力と送信後の案内まで、資料pageならdownloadやlinkまで確認します。headerの値が正しくても、埋込によって画面幅や操作が変わり、利用者が目的を果たせない場合があります。

変更を外部へ依頼する場合は、server設定の場所だけでなく、対象URLと許可先を一覧で渡します。作業後には、どのresponseへどの値を付けたか、例外にしたURLはあるか、確認したiframeは何かを受け取ります。設定を任せた相手が変わっても、外部へ表示してよいpageの判断を引き継げるようにします。

最初に一覧にするのは、iframeへ自社URLを入れている場所です。外部site、自site、社内portal、古いspecial pageを分け、表示が必要な理由を一行で書きます。必要ないものを外してから、残るURLにDENYかSAMEORIGINか、または別の導線にするかを決めます。