I'm implementing a "pass-through" for X-Frame-Options
to let a partner site wrap my employer's site in an iframe, as per this article: http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
(splitting up URLS to post)
In a nutshell, our partner's page has an iframe with an URL against our domain.
For any page in our domain, they'll add a special url argument like &@mykey=topleveldomain.com
, telling us what the page's top level domain is.
Our filters pick up the partner TLD, if provided, from the URL, and validate it against a whitelist. If it's on the list, we ship the X-Frame-Options
header with value ALLOW-FROM topleveldomain.com
(and add a cookie for future clicks). If it's not on our whitelist, we ship SAMEORIGIN
or DENY
.
The problem is it looks like sending ALLOW-FROM domain
results in a no-op overall for the latest Firefox and Google Chrome. IE8, at least, seems to be correctly implementing ALLOW-FROM
.
Check out this page: http://www.enhanceie.com/test/clickjack. Right after the 5th (of 5) boxes that "should be showing content", is a box that should NOT be showing content, but which is. In this case, the page in the iframe is sending X-Frame-Options: ALLOW-FROM http://www.debugtheweb.com
, a decidedly different TLD than http://www.enhanceie.com
. Yet, the frame still displays content.
Any insight as to whether X-Frame-Options
is truly implemented with ALLOW-FROM
across relevant (desktop) browsers? Perhaps the syntax has changed?
Some links of interest:
ALLOW-FROM is not supported in Chrome or Safari. See MDN article: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
You are already doing the work to make a custom header and send it with the correct data, can you not just exclude the header when you detect it is from a valid partner and add DENY to every other request? I don't see the benefit of AllowFrom when you are already dynamically building the logic up?