Internet Engineering Task Force (IETF) D. Ross
Request for Comments: 7034 Microsoft
Category: Informational T. Gondrom
ISSN: 2070-1721 Thames Stanley
October 2013
Internet Engineering Task Force (IETF) D. Ross
Request for Comments: 7034 Microsoft
Category: Informational T. Gondrom
ISSN: 2070-1721 Thames Stanley
October 2013
HTTP Header Field X-Frame-Options
HTTP头字段X-Frame-Options
Abstract
摘要
To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.
为了提高web应用程序对点击劫持的保护，本文档描述了X-Frame-Options HTTP标头字段，该字段声明了一个策略，该策略从服务器传送到客户端浏览器，涉及浏览器是否可以在作为其他网页一部分的帧中显示传输的内容。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7034.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7034.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. X-Frame-Options Header . . . . . . . . . . . . . . . . . . . . 4
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . . 5
2.2.1. Examples of X-Frame-Options . . . . . . . . . . . . . 6
2.3. Design Issues . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Enable HTML Content from Other Domains . . . . . . . . 6
2.3.2. Browser Behavior and Processing . . . . . . . . . . . 6
2.3.2.1. Violation of X-Frame-Options . . . . . . . . . . . 6
2.3.2.2. Variation in Current Browser Behavior . . . . . . 7
2.3.2.3. Usage Design Pattern and Example Scenario for
the ALLOW-FROM Parameter . . . . . . . . . . . . . 8
2.3.2.4. No Caching of the X-Frame-Options Header . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
3.1. Registration Template . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Browsers That Support X-Frame-Options . . . . . . . . 13
Appendix B. Description of a Clickjacking Attack . . . . . . . . 13
B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 13
B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. X-Frame-Options Header . . . . . . . . . . . . . . . . . . . . 4
2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Augmented Backus-Naur Form (ABNF) . . . . . . . . . . . . 5
2.2.1. Examples of X-Frame-Options . . . . . . . . . . . . . 6
2.3. Design Issues . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Enable HTML Content from Other Domains . . . . . . . . 6
2.3.2. Browser Behavior and Processing . . . . . . . . . . . 6
2.3.2.1. Violation of X-Frame-Options . . . . . . . . . . . 6
2.3.2.2. Variation in Current Browser Behavior . . . . . . 7
2.3.2.3. Usage Design Pattern and Example Scenario for
the ALLOW-FROM Parameter . . . . . . . . . . . . . 8
2.3.2.4. No Caching of the X-Frame-Options Header . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
3.1. Registration Template . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
4.1. Privacy Considerations . . . . . . . . . . . . . . . . . . 10
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Browsers That Support X-Frame-Options . . . . . . . . 13
Appendix B. Description of a Clickjacking Attack . . . . . . . . 13
B.1. Shop . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B.2. Online Shop Confirm Purchase Page . . . . . . . . . . . . 13
B.3. Flash Configuration . . . . . . . . . . . . . . . . . . . 13
Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 13
In 2009 and 2010, many browser vendors ([Microsoft-X-Frame-Options], [CLICK-DEFENSE-BLOG], and [Mozilla-X-Frame-Options]) introduced the use of a non-standard HTTP [RFC2616] header field "X-Frame-Options" to protect against clickjacking [Clickjacking]. HTML-based web applications can embed or "frame" other web pages. Clickjacking is a type of attack that occurs when an attacker uses multiple transparent or opaque layers in the user interface to trick a user into clicking on a button or link on another page from server B when they were intending to click on the same place of the overlaying page from server A. Thus, the attacker is "hijacking" clicks meant for page A and routing them to page B. The attacker is tricking the user (who sees the overlaying user interface content from page A) into clicking specific locations on the underlying page from server B, triggering some actions on server B and potentially using an existing session context in that step. This is an attack on both the user and on server B. In addition, server A may or may not be the attacker.
在2009年和2010年，许多浏览器供应商（[Microsoft-X-Frame-Options]、[CLICK-DEFENSE-BLOG]和[Mozilla-X-Frame-Options]）引入了非标准HTTP[RFC2616]头字段“X-Frame-Options”来防止点击劫持[clickjacking]。基于HTML的web应用程序可以嵌入或“框架”其他网页。Clickjacking是一种攻击类型，当攻击者使用用户界面中的多个透明或不透明层诱骗用户在服务器B的另一页上单击按钮或链接时，他们打算从服务器a单击覆盖页的同一位置。因此，攻击者是“劫持”单击页面A并将其路由到页面B。攻击者正在诱使用户（从页面A看到重叠的用户界面内容）从服务器B单击基础页面上的特定位置，触发服务器B上的某些操作，并可能在该步骤中使用现有会话上下文。这是对用户和服务器B的攻击。此外，服务器A可能是攻击者，也可能不是攻击者。
This specification provides informational documentation about the current use and definition of the X-Frame-Options HTTP header field. As described in Section 2.3.2.2, not all browsers implement X-Frame-Options in exactly the same way, which can lead to unintended results. And, given that the "X-" construction is deprecated [RFC6648], the X-Frame-Options header field will be replaced in the future by the Frame-Options directive in the Content Security Policy (CSP) version 1.1 [CSP-1-1].
本规范提供了有关X-Frame-Options HTTP头字段的当前使用和定义的信息文档。如第2.3.2.2节所述，并非所有浏览器都以完全相同的方式实现X-Frame-Options，这可能导致意外结果。而且，鉴于“X-”构造已被弃用[RFC6648]，X-Frame-Options头字段将在将来由内容安全策略（CSP）1.1版[CSP-1-1]中的Frame Options指令替换。
A study [FRAME-BUSTING] demonstrated that existing anti-clickjacking measures, e.g., frame-breaking JavaScript, have weaknesses that allow their protection to be circumvented.
一项研究[FRAME-BUSTING]表明，现有的反点击措施（如破坏框架的JavaScript）存在漏洞，可以绕过它们的保护。
Short of configuring the browser to disable frames and scripts entirely, which massively impairs browser utility, browser users are vulnerable to this type of attack.
如果不将浏览器配置为完全禁用框架和脚本（这会严重损害浏览器的实用性），浏览器用户很容易受到此类攻击。
The use of "X-Frame-Options" allows a web page from host B to declare that its content (for example, a button, links, text, etc.) must not be displayed in a frame (<frame> or <iframe>) of another page (e.g., from host A). This is done by a policy declared in the HTTP header and enforced by browser implementations as documented here.
“X-Frame-Options”的使用允许来自主机B的网页声明其内容（例如，按钮、链接、文本等）不得显示在另一页（例如来自主机a）的框架（<Frame>或<iframe>）中。这是由HTTP头中声明的策略完成的，并由此处记录的浏览器实现强制执行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a <frame> or an <iframe>. Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, which ensures that their content is not embedded into other pages or frames.
X-Frame-Options HTTP header字段表示一种策略，该策略指定浏览器应在<Frame>或<iframe>中呈现传输的资源。服务器可以在HTTP响应的标头中声明此策略，以防止点击劫持攻击，从而确保其内容不会嵌入到其他页面或帧中。
The header field name is:
标题字段名为：
X-Frame-Options
X-Frame-Options
There are three different values for the header field. These values are mutually exclusive; that is, the header field MUST be set to exactly one of the three values.
标题字段有三个不同的值。这些价值观是相互排斥的；也就是说，header字段必须恰好设置为三个值中的一个。
DENY A browser receiving content with this header field MUST NOT display this content in any frame.
拒绝浏览器接收具有此标题字段的内容不得在任何帧中显示此内容。
SAMEORIGIN A browser receiving content with this header field MUST NOT display this content in any frame from a page of different origin than the content itself.
SAMEORIGIN在浏览器中接收带有此标题字段的内容时，不得在任何来自与内容本身来源不同的页面的框架中显示此内容。
If a browser or plugin cannot reliably determine whether or not the origin of the content and the frame are the same, this MUST be treated as "DENY".
如果浏览器或插件无法可靠地确定内容和框架的来源是否相同，则必须将其视为“拒绝”。
Please note that current implementations vary on the interpretation of this criteria. In some, it only allows a page to be framed if the origin of the top-level browsing context is identical to the origin of the content using the X-Frame-Options directive; in others, it may consider the origin of the framing page instead. Also see Section 2.3.2.2 for more details on the nesting of frames and variations in the handling of this header field by different browsers. In addition, refer to Section 4, paragraph 2 for the resulting potential security problems.
请注意，当前的实现在对该标准的解释上有所不同。在某些情况下，仅当顶级浏览上下文的来源与使用X-Frame-Options指令的内容来源相同时，才允许对页面进行框接；在其他方面，它可以考虑框架页面的起源。另请参见第2.3.2.2节，了解框架嵌套以及不同浏览器处理此标题字段的变化的更多详细信息。此外，有关由此产生的潜在安全问题，请参阅第4节第2段。
ALLOW-FROM (followed by a serialized-origin [RFC6454]) A browser receiving content with this header MUST NOT display this content in a frame from any page with a top-level browsing context of different origin than the specified origin. While this can
ALLOW-FROM（后跟序列化源[RFC6454]）接收具有此标题的内容的浏览器不得在具有与指定源不同的顶级浏览上下文的任何页面的框架中显示此内容。而这个可以
expose the page to risks by the trusted origin, in some cases, it may be necessary to allow the framing by content from other domains.
将页面暴露于受信任来源的风险中，在某些情况下，可能需要允许通过来自其他域的内容进行框架。
The meaning of the term "serialized-origin" is given in [RFC6454]. If the ALLOW-FROM value is used, it MUST be followed by a valid origin [RFC6454] (as a subset of the URI [RFC3986]).
术语“序列化来源”的含义见[RFC6454]。如果使用了ALLOW-FROM值，则它后面必须跟一个有效的原点[RFC6454]（作为URI[RFC3986]的子集）。
Any data beyond the domain address (i.e., any data after the "/" separator) is to be ignored. The algorithm to compare origins from [RFC6454] SHOULD be used to verify that a referring page is of the same origin as the content (in the case of SAMEORIGIN) or that the referring page's origin is identical with the ALLOW-FROM serialized-origin (in the case of ALLOW-FROM). Though in conflict with [RFC6454], current implementations do not consider the port as a defining component of the origin; i.e., existing implementations differ with [RFC6454] in that origins with the same protocol but different port values are considered equivalent.
域地址之外的任何数据（即“/”分隔符后面的任何数据）都将被忽略。应使用比较[RFC6454]来源的算法来验证引用页面是否与内容来源相同（在SAMEORIGIN的情况下），或者引用页面的来源是否与ALLOW-from序列化来源相同（在ALLOW-from的情况下）。虽然与[RCF644]冲突，但当前的实现并不考虑端口作为原点的定义组件；i、 例如，现有实现与[RFC6454]的不同之处在于，源协议相同，但不同的端口值被认为是等效的。
Wildcards or lists to declare multiple domains in one ALLOW-FROM statement are not permitted (see Section 2.3.2.3).
不允许使用通配符或列表在一个ALLOW-FROM语句中声明多个域（请参阅第2.3.2.3节）。
The RFC 5234 [RFC5234] ABNF of the X-Frame-Options header field value is the following:
X-Frame-Options标头字段值的RFC 5234[RFC5234]ABNF如下所示：
X-Frame-Options = "DENY" / "SAMEORIGIN" / ( "ALLOW-FROM" RWS SERIALIZED-ORIGIN )
X-Frame-Options=“拒绝”/“SAMEORIGIN”/（“允许来自”RWS序列化源）
RWS = 1*( SP / HTAB )
; required whitespace
RWS = 1*( SP / HTAB )
; required whitespace
with serialized-origin as defined in [RFC6454] and required whitespace (RWS) as defined in [HTTPbis-P1].
具有[RFC6454]中定义的序列化源代码和[HTTPbis-P1]中定义的所需空白（RWS）。
RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS SHOULD be generated as a single space (SP). Multiple RWS octets that occur within field-content SHOULD either be replaced with a SP or transformed to all SP octets before interpreting the field value or forwarding the message downstream.
当至少需要一个线性空格八位组来分隔字段标记时，使用RWS。RW应作为单个空间（SP）生成。在解释字段值或向下游转发消息之前，字段内容中出现的多个RWS八位字节应替换为SP或转换为所有SP八位字节。
SP and horizontal tab (HTAB) are as defined in Appendix B.1 of RFC 5234 [RFC5234].
SP和水平标签（HTAB）的定义见RFC 5234[RFC5234]附录B.1。
The values are specified as ABNF strings; therefore, they are case-insensitive.
值指定为ABNF字符串；因此，它们不区分大小写。
X-Frame-Options: DENY
X帧选项：拒绝
X-Frame-Options: SAMEORIGIN
X-Frame-Options:SAMEORIGIN
X-Frame-Options: ALLOW-FROM https://example.com/
X-Frame-Options: ALLOW-FROM https://example.com/
There are a number of main direct vectors that enable HTML content from other domains, and browser implementations of X-Frame-Options cover all of them:
有许多主要的直接向量支持来自其他域的HTML内容，X-Frame-Options的浏览器实现涵盖了所有这些向量：
o IFRAME tag
o IFRAME标签
o Frame tag
o 框架标签
o Object tag (requires a redirect)
o 对象标记（需要重定向）
o Applet tag
o 小程序标记
o Embed tag
o 嵌入标签
Besides these, other ways to host HTML content can be possible. For example, some plugins may host HTML views directly. If these plugins appear essentially as frames (as opposed to top-level windows), the plugins must conform to the X-Frame-Options policy as specified in this document as well.
除此之外，还可以使用其他方式承载HTML内容。例如，一些插件可能直接承载HTML视图。如果这些插件基本上以框架形式出现（与顶级窗口相反），那么这些插件也必须符合本文档中指定的X-Frame-Options策略。
To allow secure implementations, browsers must behave in a consistent and reliable way.
为了实现安全的实现，浏览器必须以一致和可靠的方式运行。
If an X-Frame-Options HTTP header field prohibits framing, the user agent of the browser MAY immediately abort downloading or parsing of the document.
如果X-Frame-Options HTTP头字段禁止成帧，浏览器的用户代理可能会立即中止下载或解析文档。
When a browser discovers that loaded content with the X-Frame-Options header field would be displayed in a frame against the specified orders of the header, the browser SHOULD redirect to a "NOFRAME" page as soon as possible. For example, this can be a noframe.html page that also states the full URL and hostname of the protected page.
当浏览器发现加载了X-Frame-Options标题字段的内容将按照标题的指定顺序显示在框架中时，浏览器应尽快重定向到“NOFRAME”页面。例如，这可以是一个noframe.html页面，它还声明了受保护页面的完整URL和主机名。
The NOFRAME page could provide the user with an option to open the target URL in a new window.
NOFRAME页面可以为用户提供在新窗口中打开目标URL的选项。
Implementations of this vary: some browsers will show a message that allows the user to safely open the target page in a new window, whereas other implementations will simply render an empty frame.
这方面的实现各不相同：一些浏览器会显示一条消息，允许用户在新窗口中安全地打开目标页面，而其他实现只会呈现一个空框架。
There are currently variations in the implementation of the X-Frame-Options header. For example, not all browsers support the "ALLOW-FROM" option. "ALLOW-FROM" was initially an Internet Explorer extension and, at the time of writing, has not been uniformly implemented by other user agents.
X-Frame-Options标头的实现目前存在一些变化。例如，并非所有浏览器都支持“允许来自”选项。“ALLOW-FROM”最初是一个Internet Explorer扩展，在撰写本文时，其他用户代理尚未统一实现。
Furthermore, the criteria for the SAMEORIGIN (and ALLOW-FROM) directive may not be evaluated unanimously either: the known implementations in Appendix A evaluate the SAMEORIGIN directive based on the origin of the framed page and the top-level browsing context, while other implementations might evaluate it based on the framed page and the framing page, or the whole chain of nested frames in between.
此外，SAMEORIGIN（和ALLOW-FROM）指令的标准也可能无法一致评估：附录A中的已知实现基于框架页面的来源和顶级浏览上下文评估SAMEORIGIN指令，而其他实现可能会根据框架页面和框架页面，或两者之间的整个嵌套框架链对其进行评估。
To illustrate the difference between the comparison of the "framing page" and the "top-level browsing context", consider the following scenario: web pages may embed frames with other pages that, in turn, embed frames with other pages as well, and so on. In theory, this can result in an infinite nesting of framed pages. For example, web page A may contain web page B in a frame, and web page B may contain web page C in a frame.
为了说明“框架页面”和“顶级浏览上下文”的比较之间的差异，考虑下面的场景：Web页面可以嵌入其他页面的帧，而其他页面也会嵌入其他页面，等等。理论上，这可能会导致框架页面的无限嵌套。例如，网页A可以在框架中包含网页B，网页B可以在框架中包含网页C。
Web page A
<html>
....
<frame src="https://URI_of_web_page_B" />
</html>
Web page A
<html>
....
<frame src="https://URI_of_web_page_B" />
</html>
Web page B
<html>
....
<frame src="https://URI_of_web_page_C" />
</html>
Web page B
<html>
....
<frame src="https://URI_of_web_page_C" />
</html>
and so forth.
等等
In this example, for the nested frames with the inner-framed web page C, the most outer web page A would be the "top-level browsing context", and web page B would be the "framing page".
在本例中，对于具有内部框架网页C的嵌套框架，最外层网页A将是“顶级浏览上下文”，而网页B将是“框架网页”。
These potential variations in the evaluation of the header by different implementations impair the usage and reliability of this HTTP header and have security implications as described in Section 4. A revised version of X-Frame-Options in the form of a Frame-Options directive in CSP 1.1 [CSP-1-1] will unify the behavior, and it is expected that newer implementations will use it rather than the mechanisms documented here.
不同实现对报头评估的这些潜在变化损害了此HTTP报头的使用和可靠性，并具有第4节所述的安全含义。CSP 1.1[CSP-1-1]中的框架选项指令形式的X-Frame-Options修订版将统一该行为，预计较新的实现将使用它，而不是此处记录的机制。
2.3.2.3. Usage Design Pattern and Example Scenario for the ALLOW-FROM Parameter
2.3.2.3. ALLOW-FROM参数的使用设计模式和示例场景
As the "ALLOW-FROM" field only supports one serialized-origin, in cases when the server wishes to allow more than one resource to frame its content, the following design pattern can fulfill that need:
由于“ALLOW-FROM”字段仅支持一个序列化源，因此，在服务器希望允许多个资源对其内容进行帧处理的情况下，以下设计模式可以满足这一需求：
1. A page that wants to render the requested content in a frame supplies its own origin information to the server providing the content to be framed via a query string parameter.
1. 要在框架中呈现请求的内容的页面通过查询字符串参数向提供要框架的内容的服务器提供自己的源信息。
2. The server verifies that the hostname meets its criteria, so that the page is allowed to be framed by the target resource. This may, for example, happen via a lookup of a whitelist of trusted domain names that are allowed to frame the page. For example, for a Facebook "Like" button, the server can check to see that the supplied hostname matches the hostname(s) expected for that "Like" button.
2. 服务器验证主机名是否符合其标准，以便允许目标资源对页面进行框架设置。例如，这可能是通过查找允许框显页面的受信任域名的白名单来实现的。例如，对于Facebook的“Like”按钮，服务器可以检查提供的主机名是否与该“Like”按钮预期的主机名匹配。
3. The server returns the hostname in "X-Frame-Options: ALLOW-FROM" if the proper criteria was met in step #2.
3. 如果在步骤2中满足适当的条件，服务器将在“X-Frame-Options:ALLOW-FROM”中返回主机名。
4. The browser enforces the "X-Frame-Options: ALLOW-FROM" header.
4. 浏览器强制执行“X-Frame-Options:ALLOW-FROM”标题。
Caching the X-Frame-Options header for a resource is not recommended. Caching the X-Frame-Options response could result in problems because:
不建议缓存资源的X-Frame-Options标头。缓存X-Frame-Options响应可能会导致问题，因为：
1. For every http-request of the resource, the browser has to check whether the X-Frame-Options header has been set and then act accordingly, as a resource itself might be created dynamically and the header could change with it, too.
1. 对于资源的每个http请求，浏览器必须检查X-Frame-Options标头是否已设置，然后相应地执行操作，因为资源本身可能会动态创建，并且标头也可能随之更改。
2. Also, as outlined in Section 2.3.2.3, servers may generate X-Frame-Options header responses depending on the request. Example case: Considering that we have only one serialized-origin in the ALLOW-FROM directive, imagine a user has multiple pages open in his browser tabs with web page 1 from domain A and web
2. 此外，如第2.3.2.3节所述，服务器可能会根据请求生成X-Frame-Options报头响应。示例案例：考虑到我们在ALLOW-FROM指令中只有一个序列化源，假设用户在浏览器选项卡中打开了多个页面，其中包含来自域a和web的网页1
page 2 from domain B, and both frame the same page from domain C with the ALLOW-FROM directive. In that case, the page needs to reply to both requests with different X-Frame-Options headers, with the first pointing to origin A and the second pointing to origin B.
域B中的第2页，以及使用ALLOW-from指令框接域C中的同一页。在这种情况下，页面需要使用不同的X-Frame-Options头响应两个请求，第一个指向原点A，第二个指向原点B。
However, we found that none of the major browsers listed in Appendix A cache the responses.
然而，我们发现附录A中列出的主要浏览器都没有缓存响应。
IANA has included the specified HTTP header in the "Permanent Message Header Field Name" registry as outlined in "Registration Procedures for Message Header Fields" [RFC3864].
IANA已将指定的HTTP头包含在“永久消息头字段名称”注册表中，如“消息头字段的注册程序”[RFC3864]所述。
Permanent Message Header Field Names Template:
永久邮件标题字段名称模板：
Header field name: X-Frame-Options
标题字段名称：X-Frame-Options
Applicable protocol: http [RFC2616]
适用协议：http[RFC2616]
Status: Informational
状态：信息性
Author/change controller: IETF
作者/变更控制员：IETF
Specification document(s): RFC 7034
规范文件：RFC 7034
Related information: None
相关信息：无
The introduction of the X-Frame-Options HTTP header field improves the protection against clickjacking. However, it is not self-sufficient enough to protect against all kinds of these attack vectors. It must be used in conjunction with other security measures like secure coding (e.g., input validation, output encoding, etc.) and the Content Security Policy version 1.0 [CSP].
X-Frame-Options HTTP头字段的引入提高了对点击劫持的保护。然而，它还不能自给自足地抵御所有类型的攻击向量。它必须与安全编码（如输入验证、输出编码等）和内容安全策略1.0版[CSP]等其他安全措施结合使用。
It is important to note that current implementations do not check the origins of the framing resources' entire ancestor tree of frames, and this may expose the resource to attack in multiple-nested scenarios.
需要注意的是，当前的实现没有检查框架资源的整个框架祖先树的起源，这可能使资源在多个嵌套场景中受到攻击。
The browser implementations evaluate based on the origin of the framed page and the top-level browsing context (i.e., the most outer frame):
浏览器实现基于框架页面的原点和顶级浏览上下文（即最外层框架）进行评估：
If a resource from origin A embeds untrusted content from origin B, that untrusted content can embed another resource from origin A with an "X-Frame-Options: SAMEORIGIN" policy, and that check would pass when the user agent only verifies the top-level browsing context. Therefore, web developers should be aware that embedding content from other sites can leave their web pages vulnerable to clickjacking even if the X-Frame-Options header is used.
如果源a的资源嵌入了源B的不受信任内容，则该不受信任内容可以使用“X-Frame-Options:SAMEORIGIN”策略嵌入源a的另一个资源，并且当用户代理仅验证顶级浏览上下文时，该检查将通过。因此，web开发人员应该意识到，即使使用了X-Frame-Options标题，嵌入其他网站的内容也会使其网页容易被点击劫持。
Furthermore, X-Frame-Options must be sent as an HTTP header field and is explicitly ignored by user agents when declared with a meta http-equiv tag.
此外，X-Frame-Options必须作为HTTP头字段发送，当使用meta HTTP equiv标记声明时，用户代理会显式忽略。
There are two kinds of potential data leakage to consider:
需要考虑两种潜在的数据泄漏：
1. Using X-Frame-Options with the parameter ALLOW-FROM allows a page to guess or infer information about who is framing it. A web server may answer requests with the "X-Frame-Options: ALLOW-FROM" header and thus determine which other page is framing it. This is inherent by design, but it may lead to data-leakage or data-protection concerns.
1. 将X-Frame-Options与参数ALLOW-FROM一起使用，允许页面猜测或推断有关谁在为其设置框架的信息。web服务器可以使用“X-Frame-Options:ALLOW-FROM”标题回答请求，从而确定哪个页面正在构建它。这在设计上是固有的，但可能会导致数据泄漏或数据保护问题。
2. The web server using the ALLOW-FROM directive effectively discloses the origin specified in the header. If a web server wishes to reduce this leakage, it is recommended to generate the ALLOW-FROM header for each request based on the design pattern as described in Section 2.3.2.3.
2. 使用ALLOW-FROM指令的web服务器有效地公开了头中指定的来源。如果web服务器希望减少此泄漏，建议根据第2.3.2.3节中描述的设计模式为每个请求生成ALLOW-FROM标头。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, December 2011.
[RFC6454]Barth，A.，“网络起源概念”，RFC 64542011年12月。
[CLICK-DEFENSE-BLOG] Lawrence, E., "IE8 Security Part VII: Clickjacking Defenses", Microsoft Developer Network Blogs, January 2009, <http://blogs.msdn.com/b/ie/archive/2009/01/ 27/ie8-security-part-vii-clickjacking-defenses.aspx>.
[CLICK-DEFENSE-BLOG]Lawrence，E.，“IE8安全第七部分：点击劫持防御”，微软开发者网络博客，2009年1月<http://blogs.msdn.com/b/ie/archive/2009/01/ 27/ie8安全第七部分点击劫持防御。aspx>。
[CSP] Sterne, B. and A. Barth, "Content Security Policy 1.0", W3C Candidate Recommendation CR-CSP-20121115, November 2012, <http://www.w3.org/TR/2012/CR-CSP-20121115/>.
[CSP]Sterne，B.和A.Barth，“内容安全策略1.0”，W3C候选建议CR-CSP-201211115，2012年11月<http://www.w3.org/TR/2012/CR-CSP-20121115/>.
[CSP-1-1] Barth, A. and M. West, "Content Security Policy 1.1", W3C Working Draft WD-CSP11-20130604, June 2013, <http://www.w3.org/TR/2013/WD-CSP11-20130604/>.
[CSP-1-1]Barth，A.和M.West，“内容安全政策1.1”，W3C工作草案WD-CSP11-201306042013年6月<http://www.w3.org/TR/2013/WD-CSP11-20130604/>.
[CSRF] OWASP (Open Web Application Security Project), "Top-10 2013-A8-Cross-Site Request Forgery (CSRF)", June 2013, <https://www.owasp.org/index.php/ Top_10_2013-A8-Cross-Site_Request_Forgery_%28CSRF%29>.
[CSRF]OWASP（开放式Web应用程序安全项目），“Top-10 2013-A8-跨站点请求伪造（CSRF）”，2013年6月<https://www.owasp.org/index.php/ Top\u 10\u 2013-A8-跨站点请求\u伪造\u%28CSRF%29>。
[Clickjacking] OWASP (Open Web Application Security Project), "Clickjacking", April 2013, <http://www.owasp.org/index.php/Clickjacking>.
[Clickjacking]OWASP（开放式Web应用程序安全项目），“Clickjacking”，2013年4月<http://www.owasp.org/index.php/Clickjacking>.
[FRAME-BUSTING] Stanford Web Security Research, "Busting frame busting: a study of clickjacking vulnerabilities at popular sites", July 2010, <http://seclab.stanford.edu/websec/framebusting/>.
[框架破坏]斯坦福网络安全研究，“框架破坏：流行网站点击劫持漏洞研究”，2010年7月<http://seclab.stanford.edu/websec/framebusting/>.
[HTTPbis-P1] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", Work in Progress, September 2013.
[HTTPbis-P1]Fielding，R.和J.Reschke，“超文本传输协议（HTTP/1.1）：消息语法和路由”，正在进行的工作，2013年9月。
[Microsoft-X-Frame-Options] Lawrence, E., "Combating ClickJacking With X-Frame-Options", Microsoft Developer Network Blogs, March 2010, <http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/ combating-clickjacking-with-x-frame-options.aspx>.
[Microsoft-X-Frame-Options]Lawrence，E.，“用X-Frame-Options打击点击劫持”，微软开发者网络博客，2010年3月<http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/ 单击jacking-with-x-frame-options.aspx>。
[Mozilla-X-Frame-Options] Mozilla Developer Network, "The X-Frame-Options response header", August 2013, <https://developer.mozilla.org/ en-US/docs/The_X-FRAME-OPTIONS_response_header>.
[Mozilla-X-Frame-Options]Mozilla开发者网络，“X-Frame-Options响应标题”，2013年8月<https://developer.mozilla.org/ en-US/docs/The\u X-FRAME-OPTIONS\u response\u header>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the "X-" Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, June 2012.
[RFC6648]圣安德烈，P.，克罗克，D.，和M.诺丁汉，“反对应用协议中的“X-”前缀和类似结构”，BCP 178，RFC 6648，2012年6月。
o Internet Explorer 8+
o Internet Explorer 8+
o Firefox 3.6.9+
o 火狐3.6.9+
o Opera 10.5+
o 歌剧10.5+
o Safari 4+
o 狩猎4+
o Chrome 4.1+
o 铬4.1+
A more detailed explanation of clickjacking scenarios follows.
下面将对点击劫持场景进行更详细的解释。
An Internet marketplace/shop offering a feature with a link/button to "Buy this" gadget wants their affiliates (who could be malicious attackers) to be able to stick the "Buy such and such from XYZ" IFRAMES into their pages. There is a possible clickjacking threat here, which is why the marketplace/online shop needs to then immediately navigate the main browsing context (or a new window) to a confirmation page that is protected by anti-clickjacking protections.
一家互联网市场/商店提供一个带有“购买此”小工具的链接/按钮的功能，希望其附属公司（可能是恶意攻击者）能够将“从XYZ购买某物”iFrame粘贴到其页面中。这里可能存在点击劫持威胁，这就是为什么市场/在线商店需要立即将主浏览上下文（或新窗口）导航到受反点击劫持保护的确认页面。
The "Confirm Purchase" page of an online shop must be shown to the end-user without the risk of an overlay or misuse by an attacker. For that reason, the confirmation page uses a combination of anti-CSRF (Cross Site Request Forgery [CSRF]) tokens and the X-Frame-Options HTTP header field, mitigating clickjacking attacks.
必须向最终用户显示在线商店的“确认购买”页面，而不存在被攻击者覆盖或滥用的风险。因此，确认页面使用反CSRF（跨站点请求伪造[CSRF]）令牌和X-Frame-Options HTTP头字段的组合，从而减轻点击劫持攻击。
Macromedia Flash configuration settings are set by a Flash object that can run only from a specific configuration page on Macromedia's site. The object runs inside the page and thus can be subject to a clickjacking attack. In order to prevent clickjacking attacks against the security settings, the configuration page uses the X-Frame-Options directive.
Macromedia Flash配置设置由只能从Macromedia站点上的特定配置页面运行的Flash对象设置。该对象在页面内部运行，因此可能受到点击劫持攻击。为了防止针对安全设置的点击劫持攻击，配置页面使用X-Frame-Options指令。
This document was derived from input from specifications published by various browser vendors such as Microsoft (Eric Lawrence and David Ross), Mozilla, Google, Opera, and Apple.
本文档来源于微软（Eric Lawrence和David Ross）、Mozilla、谷歌、Opera和苹果等浏览器供应商发布的规范。
Authors' Addresses
作者地址
David Ross Microsoft
大卫罗斯微软公司
EMail: dross@microsoft.com
EMail: dross@microsoft.com
Tobias Gondrom Thames Stanley
泰晤士河斯坦利酒店
EMail: tobias.gondrom@gondrom.org
EMail: tobias.gondrom@gondrom.org