Security Research
Showing results for 
Search instead for 
Do you mean 

The Underappreciated X-Frame-Options Header

‎03-07-2013 06:47 PM - edited ‎03-07-2013 07:36 PM

While in San Francisco last week for the 2013 RSA Conference, some of us made the trek to B-Sides to catch a few talks since we arrived a bit early. To our delight, Mike Shema was speaking about  JavaScript Security & HTML5 and we were eager to see his presentation. Mike also gave another talk at RSA about using HTML5 WebSockets securely, which was equally informative and engaging (however, I preferred the ambiance of the DNA Lounge for the first presentation).


Back to B-Sides. It didn’t take long for Mike to mention the HTML5 Iframe tag and the sandbox attribute. Quite a timely mention, given that we’d spent the better part of the last few months studying Cross-Frame Scripting (XFS) and Clickjacking attacks for our contribution to the HP 2012 Cyber Risk Report. Immediately following this discussion was the mention of the X-Frame-Options header and how it effectively discourages Clickjacking attacks. Where Mike stopped short, however, is answering the question we posed at the beginning of our research project, “Just how many developers are using the X-Frame-Options header?”


Disappointingly, even in the face of stout remediation measures such as the X-Frame-Options header, XFS continues to exist and has enabled other, more popular vulnerabilities such as Clickjacking to take root and flourish. One of the most surprising findings we uncovered throughout our research was the sheer number of websites that didn’t even attempt to set the X-Frame-Options header, which could just be because they don’t need it. Or do they?


As a test, we figured we’d create a simple script to passively examine top level requests for information worth protecting – so we decided to look for HTTP responses that contained password fields as an initial gauge to pages that actually had a reason to protect something sensitive. The HP 2012 Cyber Risk Report contains the details of our findings, but a quick spoiler alert will tell you that less than a tenth of a percent of our sample included proper use of the X-Frame-Options header.


It’s difficult to explain the grounds for why there’s such a wicked absence of websites incorporating the X-Frame-Options header.  Could it be that developers don’t understand the threat of Clickjacking or the X-Frame-Options header just hasn’t been properly evangelized enough for developers to take it seriously? Either way, the X-Frame-Options header is indeed an effective deterrent to Clickjacking, but only if it’s used!


One common misconception is that client-side frame-busting JavaScript takes care of XFS. While a few “frame-buster-buster” iterations went around for a few years, the HTML5 IFrame tag coupled with a sandbox attribute that neglects to specify the “allow-top-navigation” permission in its value effectively disables this protection…so it’s even more imperative to use the X-Frame-Options header now more than ever.


There are several helpful resources on how and why you should incorporate the X-Frame-Options response header in your applications, here are a few:


  1. OWASP:
  2. For IIS:
  3. For Apache, nginx:
  4. Busting Frame Busting: A Study of Clickjacking Vulnerabilities on Popular Sites
  5. X-Frame-Options IETF Draft:

0 Kudos
About the Author


Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all