Updated: January 29th, 2010

image Today I found out something entirely new about framebusting and specifically clickjacking protection techniques.

I was working with a site that was using frames. Suddenly, one of the frames (which was hosted on a domain that differed from the one it was embedded in) displayed the following message (in Firefox 3.5.4):

This content cannot be displayed in a frame
To protect your security, the publisher of this content does
not allow it to be displayed in a frame.
Click here to open this content in a new window


Notice how this is a native Firefox window and not a web page rendering. Quite stumped, I started looking at the frame response and finally found that it included this little header:


Turns out that modern browsers like Firefox 3.5 (turns out it's the NoScript addon that does this and not Firefox itself) and IE8 treat this header as a precautionary measure and display a generic "warning" to the user instead of the page content in certain conditions described below. This effort, led, surprisingly, by Microsoft, was really to protect users from clickjacking (I wrote about clickjacking here earlier) but can be viewed as an alternative to framebusting.

Microsoft introduced the new X-FRAME-OPTIONS header with the following possible values:

  • DENY – prevents the page from being rendered if it is contained in a frame
  • SAMEORIGIN – same as above, unless the page belongs to the same domain as the top-level frameset holder.

Firefox adopted this technique a few months later (again, I was wrong here – it was NoScript that did it), and I expect other browsers to follow.

So what does it mean to you, the developer?

  • setting such a header will essentially render frame busting code unnecessary in modern browsers
  • but it has a downside of displaying a relatively ugly warning to the user
  • no automatic redirect is done as your page (including any framebusting code) is not loaded
  • thus requiring an extra click
  • and popping up a new tab or window
  • it will work even if the user has Javascript disabled, which is more secure

Some useful discussion on the issue can also be found in this post on Hackademix.net.

So is it good practice to use this new X-FRAME-OPTIONS header instead of the traditional framebusting code? I definitely think so, especially if Firefox and other browsers start supporting it. What do you say?

● ● ●
Artem Russakovskii is a San Francisco programmer and blogger. Follow Artem on Twitter (@ArtemR) or subscribe to the RSS feed.

In the meantime, if you found this article useful, feel free to buy me a cup of coffee below.