Skip to main content

HTTP Header Field X-Frame-Options
draft-ietf-websec-x-frame-options-12

Yes

(Barry Leiba)

No Objection

(Adrian Farrel)
(Brian Haberman)
(Jari Arkko)

Note: This ballot was opened for revision 08 and is now closed.

Barry Leiba Former IESG member
Yes
Yes (for -08) Unknown

                            
Richard Barnes Former IESG member
(was Discuss) Yes
Yes (2013-08-14 for -11) Unknown
(C1) In the Introduction, the phrase "secure web page" would seem to imply that this mechanism only applies to pages delivered over HTTPS, which I'm pretty sure isn't true.  Suggest just deleting "secure".

(C2) In Section 2.1, the sentence starting "And the algorithm" seems to imply that ALLOW-FROM allows SAMEORIGIN requests as well, which I think you actually mean something like:
"""
And 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 URI (in the case of ALLOW-FROM). 
"""
Stephen Farrell Former IESG member
Yes
Yes (2013-08-14 for -09) Unknown
(Personal opinion only, no change requested unless it
resonates with folks.) I would prefer that this not say
that NoScript impairs broswer utility. I find it fine.

Other than that, this is a fine draft, thanks.
Adrian Farrel Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (2013-08-14 for -09) Unknown
support richards discussion, the security/privacy considerations could use some wordsmithing.
Pete Resnick Former IESG member
No Objection
No Objection (2013-08-14 for -09) Unknown
Why is this document not on the standards track?
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2013-08-14 for -10) Unknown
I'd ask about how RFC 6648 applies to this, but I bet this header was out long before the drafts that lead to RFC 6648.

s1 (penultimate paragraph): r/script/Javascript ?

s4.1: Is Figure 1 missing or is that the registration template? ;)

s5:
r/all kinds of these attack vectors/these kind of attack vectors
r/, ...)/)

Appendix A: Is this a guarantee that x-frame-options/frame-options will be supported henceforth until the end of time in those browsers?  Basically, I'm not sure Appendix A is needed.
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-08-12 for -08) Unknown
I really like this specification, and I appreciate the working group producing it. Documenting "in the wild" behavior is a good thing.

I have one fairly fundamental comment, which I think can be easily addressed, and a few nits.

My comment: This specification starts out like a normal header field specification until you get to 

1.  Introduction

   This specification provides informational documentation about the
   current use and definition of the X-Frame-Options HTTP header field.
   Given that the "X-" construction is deprecated [RFC6648], the X
   -Frame-Options header field will in the future be replaced by the
   Frame-Options directive in the Content Security Policy Version 1.1
   [CSP-1-1]. 

That's still KIND of OK (no indication that anything is wrong with X-FRAME-OPTIONS functionality, just a heads-up that implementations that include X-FRAME-OPTIONS will have work to do in the future), but when we get to 

2.3.2.2.  Variation in current browser behaviour

   There are currently variations in the implementation of the X-FRAME-
   OPTIONS header. 

we discover unambiguously that current implmentations don't all work the same way, so your ability to rely on X-FRAME-OPTIONS is not entirely clear.

I wonder if the set of technical details are asperational, saying "this is what X-FRAME-OPTIONS could have been, and what the next header field in this space should be".

I think it's fine to publish this specification, especially as Informational, even if it's not clear to me that *any* of the functionality described in this specification is implemented the same way in all major browsers.

I would be more comfortable with a clear statement in the Introduction that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-", but that today's implementations don't all provide the same options with the same behaviors, so relying on this specification as a predictor of what will happen to your frames is not a good idea. 

One sentence that puts the reader on notice would be sufficient.

My nits, just so editors don't have to find them again:

Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other times not? I'm not an APP guy, so I'm asking.

In Section 2.3.2.2.  Variation in current browser behaviour

   These variations in the evaluation of the header by different
   implementations impair the useage and reliability of this http
   header.  A revised version of x-frame-options in the form of a frame-
   options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
   and it is expected that newer implementations will use it rather than
   the mechanisms documented here"

The trailing quote mark should be a period, I suppose?

5.1.  Privacy Considreations should be "Considerations".

In B.2.  Online Shop Confirm Purchase Page

   The "Confirm Purchase"" 

The doubled trailing quote marks should be one quote mark, perhaps?
Ted Lemon Former IESG member
No Objection
No Objection (2013-08-14 for -09) Unknown
The introduction of the concept of origins in 2.1 is a bit clumsy—the term is used under the SAMEORIGIN heading without being defined, and is later defined as a constraint specific only to ALLOW-FROM.   Text about browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here and in later sections.   It would be better to simply refer to the later section.   If I were to clean up this section, I would do something like the following:

DENY
         A browser receiving content with this header 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.
         If a browser or plugin can not reliably determine whether the
         origin of the content and the frame have the same origin, this
         MUST be treated as "DENY".   Section 2.3.2.2 documents
         variations in the handling of this header field by different
         browsers.

   ALLOW-FROM  (followed by a URI [RFC3986] of a trusted origin)
         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 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 "origin" is given in [RFC6454].
   If the ALLOW-FROM value is used, it MUST be followed by a valid URI.
   Any data beyond the domain address (i.e.  any data after the "/"
   separator) is to be ignored.  And the algorithm to compare origins
   from [RFC6454] SHOULD be used to verify that a referring page is of
   the same origin as the content or that the referring page's origin is
   identical with the ALLOW-FROM URI.  Though in conflict with
   [RFC6454], current implementations do not consider the port as a
   defining component of the origin.

I also noticed that in another exchange about this document, someone said that this document is not intended to give advice to browser vendors.   If that's the case, what is the above SHOULD doing in the text?   Is there uncertainty as to what implementations do?   If so, it would be better to express that uncertainty, if indeed you are documenting browser behavior.

Also, with respect to this text:

   Though in conflict with
   [RFC6454], current implementations do not consider the port as a
   defining component of the origin.

Does this mean that http://www.foo.com and http://www.foo.com:8080 are considered equivalent, or that http://www.foo.com and http://www.foo.com:80 are _not_ considered equivalent?   What about http://www.foo.com and https://www.foo.com?

The following text is incomprehensible to me as a non-domain-expert:

   The criteria for the SAMEORIGIN option is not evaluated unanimously
   either: one implementation may evaluate the SAMEORIGIN option based
   on the origin of the framed page and the framing page, while another
   may evaluate based on the framed page and the top-level browsing-
   context.

What is the distinction between "top-level browsing context" and "origin of the framing page?"   A reference here would be helpful.

Thanks for documenting this.