Intent to ship: Changes to ‘X-Frame-Options: SAMEORIGIN’

Jonathan Kingston

unread,

Nov 27, 2017, 10:32:20 AM11/27/17

to dev-platform

Currently XFO only enforces same origin checks of the loading frame against
the top-level document when the SAMEORIGIN value is set[1][2]. However, XFO
does not check the entire ancestor chain before making a decision whether
the load should be allowed or blocked.

In more detail, a load of: a.com -> b.com -> a.com would currently allow
frame a.com to be loaded. We plan to change that behavior so that for
X-Frame-Options the entire ancestors chain is consulted when the value
SAMEORIGIN is specified. In turn, that change of behavior would block the
iframe of a.com because the middle iframe has an origin of b.com.

Please note that ALLOW-FROM or any other XFO values will not be affected by
that change. As Chrome does not implement the ALLOW-FROM behavior, web
sites shipping with an XFO header of ALLOW-FROM might not load in all
circumstances. However, developers relying on that behavior could ship a
CSP using frame-ancestors instead [3].

Chrome implemented the ancestor checks to SAMEORIGIN in Chrome 61[4] and
has no intent to remove and no issues have been filed in the last ~4
months. Based on Chrome's telemetry the usage is ~0% making the impact very
low risk.

This change is covered by web platform tests in:
https://github.com/w3c/web-platform-tests/tree/master/x-frame-options

We track overall progress here:
https://bugzilla.mozilla.org/show_bug.cgi?id=725490

Thanks

Jonathan

[1]
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options

[2] https://tools.ietf.org/html/rfc7034

[3] https://w3c.github.io/webappsec-csp/#directive-frame-ancestors

[4]
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/fsDaKFqvU20

Luke Crouch

unread,

Nov 27, 2017, 8:51:57 PM11/27/17

to

On Monday, November 27, 2017 at 9:32:20 AM UTC-6, Jonathan Kingston wrote:
> Currently XFO only enforces same origin checks of the loading frame against
> the top-level document when the SAMEORIGIN value is set[1][2]. However, XFO
> does not check the entire ancestor chain before making a decision whether
> the load should be allowed or blocked.
>
> In more detail, a load of: a.com -> b.com -> a.com would currently allow
> frame a.com to be loaded. We plan to change that behavior so that for
> X-Frame-Options the entire ancestors chain is consulted when the value
> SAMEORIGIN is specified. In turn, that change of behavior would block the
> iframe of a.com because the middle iframe has an origin of b.com.

I like the change, but I'm scratching my head for example code? Would this be ...

on a.com
<iframe src="b.com/include-a">
<html>
<iframe src="a.com/included">
</html>
</iframe>

It seems SAMEORIGIN would block the loading of b.com/include-a in the first place, so how will it know that b.com is including a.com?

Jonathan Kingston

unread,

Nov 27, 2017, 9:54:08 PM11/27/17

to Luke Crouch, dev-platform

I think you might be getting confused between frame-src and frame-ancestors.

"frame-src" is a allowlist for frames that can be loaded into the web page.
"frame-ancestors" is an allowlist of documents that can frame the web page.

So in your example code:

on a.com
<iframe src="b.com/include-a">
<html>
<iframe src="a.com/included">
</html>
</iframe>

X-Frame-Options behaves like frame-ancestors so SAMEORIGIN applies to
a.com/included, a.com sends a XFO it prevents b.com from loading a.com.
This currently is only true when b.com is the top level and not also a
subframe.

So for example a page using XFO as a defence against being framed by other
websites actually could have content of their own website presented within
for example an advert network on the site.

Thanks
Jonathan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>