Updated: January 29th, 2010

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 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:

X-FRAME-OPTIONS: DENY X-FRAME-OPTIONS: DENY

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?