The mess with X-Frame-Options: ALLOWALL

2013-02-28 00:00:00 +0000

Seemingly a quite new invention, X-Frame-Options option “ALLOWALL”, comes amid the standardization process of X-Frame-Options header. X-Frame-Options is a poor man’s replacement for CSP that has been around since 2009 and initially it had just two values: DENY and SAMEORIGIN. Later on someone has added ALLOW-FROM and these three values together found their way into an upcoming IETF standard (draft-ietf-websec-x-frame-options).

So I was very suprised to see Google (!) AdSense servers return a previously unseen value of ALLOWALL, that is documented nowhere else — except for this article (from now on) and a recent (2 days ago) request to add it to WebKit (Bug 110857 and patch). Here’s description of the change:

DoubleClick, among others, serves ALLOWALL as a 'X-Frame-Options' value with the intent of (shock!) allowing a resource to be framed by all origins. Given its prevelance, and the fact that IE supports the header, we shouldn't call it out as invalid.

I don’t quite get it. If you allow your content to be framed, you just do not set X-Frame-Options. What is even even more surprising, all that the patch does is to disable console warnings in WebKit, without really changing any frames logic.

Here’s how the JavaScript console warning looks like in Chrome 25:

Invalid 'X-Frame-Options' header encountered when loading '': 'ALLOWALL' is not a recognized directive. The header will be ignored.

Here’s full HTTP response from captured in the wild:

cache-control:private content-length:0 content-type:text/html; charset=UTF-8 date:Thu, 28 Feb 2013 16:55:19 GMT expires:Thu, 28 Feb 2013 16:55:19 GMT p3p:policyref="", CP="CURa ADMa DEVa TAIo PSAo PSDo OUR IND UNI PUR INT DEM STA PRE COM NAV OTC NOI DSP COR" server:safe set-cookie:_drt_=OPT_OUT; expires=Fri, 01-Mar-2013 16:55:19 GMT; path=/;; HttpOnly status:200 OK version:HTTP/1.1 x-content-type-options:nosniff x-frame-options:ALLOWALL x-xss-protection:1; mode=block