As I promised in my previous posts about so called IE8's "Clickjacking protection", some hours ago I released the NoScript development build, featuring experimental but complete compatibility with the X-FRAME-OPTIONS header support introduced by IE8 and unveiled yesterday by Eric Lawrence on the IE Blog.

As I said previously,

this is just a cross-browser compatibility effort: neither Firefox nor NoScript really need this feature. Traditional JavaScript-based frame busting works fine in Firefox, giving it the same degree of (modest) "protection" as IE8. NoScript users, on the other hand, are already fully protected, because ClearClick is the one and only countermeasure which works against any type of Clickjacking (frame or embed based), no matter if web sites cooperate or not.

However I also said this is nice to have. I had already imagined a functionally similar declarative solution, the SUB pseudo-method of ABE rules, and HTTP-based restrictions can actually be easier to deploy in some scenarios (e.g. using a Web Application Firewall).

More important, not every IT manager will have a chance of reading the reasons I exposed so far, explaining why IE8 has no more "Clickjacking protection" than its competitors. Our typical decision maker will just read a bullet list including "Clickjacking protection", will find that no other browser dares such a claim and will base his choice (also) on that misleading comparison.

So let's add this bullet, even if it does nothing against Clickjacking that "alternative browsers" couldn't already do with traditional frame busting.

The following screenshot shows the original IE8 implementation as can be tested on my demo page:

X-IFRAME-OPTIONS demo in IE8 screenshot

And this is X-IFRAME-OPTIONS in action on Firefox (kindly provided by NoScript for now, but already in the works as a built-in):

X-IFRAME-OPTIONS demo in Firefox screenshot

But now that we've got "bullet parity", let's put the marketspeak aside and keep enjoying the only Clickjacking protection that really works "out of the box": your friendly neighborhood ClearClick :)

15 Responses to “X-FRAME-OPTIONS in Firefox”

  1. #1 alanjstr says:

    Hey. There was an article today (on ZDNet I think) about clickjacking in all the browsers. Are there bugs for all the features you've put in NoScript? Maybe track them all with a metabug I could subscribe to?

  2. #2 anonymous says:

    Ohh for god's sake .. how many times will you tell "only protection that works out of the box"

    we get it ... we are not idiots!!!

    are you writing a blog targetting idiots - the way ads on television are ? we get it when you tell us once - this post could have just been - I added support in noScript check out the screenshots - everything else you have already said in previous posts.

  3. #3 Giorgio says:

    I know some people may get it just saying it once.

    But I've got to target people like Larry Seltzer here at Security Watch, who unluckily are also opinion leaders.

    Sorry for the inconvenience.

  4. #4 pirlouy says:

    Bah; it does not bother me. But I'm an idiot, so... :-)

  5. #5 Giorgio says:

    Larry Seltzer posted a rectification, honestly admitting he had been mislead about by the old original RSnake's Clickjacking details post (which, by the way, actually said that current -- three months ago -- NoScript versions did protect against Clickjacking, opposite to older versions which could be circumvented).

    Anyway, thanks Larry, I did appreciate that, even though I couldn't post not even a simple "Thanks" as a comment on your blog, because of the unbelievable suckiness of PCMag's spam filters...

  6. #6 » All That ClickJazz... says:

    [...] protection which will work on those pages whose authors decide to adopt the new proprietary X-FRAME-OPTIONS header (now cross-browser), interest of the press about this topic has been raising again. Unluckily, Clickjacking (or more [...]

  7. #7 Joris van der Wel says:

    Just did some tests and it appears that "X-IFRAME-OPTIONS" does not work with <object data=""></object>.

    Also, I have noticed that sometimes the link "Click here to open this content in a new window" will open the chrome url of the error message instead of the page. Unfortunately I am not sure how to properly recreate this.

    Also, awesome extension

    Gr. Joris

  8. #8 Giorgio says:

    Fixed in, thanks.
    Notice that you won't get an error message for OBJECT elements, but the request gets blocked anyway.

  9. #9 MacOtaku says:

    I know it's a small issue, but this feature should allow the user to override it, so it isn't misused. Unfortunately, unlike JS frame busting, there is presently no practical means for the user to override this feature when it is abused by web publishers. For example, if a page doesn't want to be framed, not for security, but as part of yet another obnoxious, paranoid, and ineffective "copy-protection" scheme (like those "clever" scripts that set onselectstart, etc to function(){return false}), and I land on said page framed as a Google image search result, I can stop it from frame-busting by denying its JS. (Actually, can I -- or does NoScript prevent me from stopping it by emulating frame-busting without consulting the user?) Now, if the HTTP header is honoured without giving the user a means to override it, how then do I prevent the page messing up a legitimate framing (such as an result, or a Facebook posted item)?

  10. #10 Giorgio says:

    "Traditional" frame busting emulation is controlled by the noscript.emulateFrameBreak about:config preference.
    I can add a similar preference for X-FRAME-OPTIONS in next release (it was already planned, anyway).

  11. #11 » Browser Plugins, Add-Ons and Security Advisers says:

    [...] send Roger an email, sparking a pretty intense exchange (in the meanwhile, I was implementing PoC X-Frame-Options compatibility for Firefox with my left [...]

  12. #12 Open Source Firefox Extension NoScript Updated | Infosecurity.US says:

    [...] incident reporting tool. Improved script blocking and scriptless pages management. Improved X-FRAME-OPTIONS compatibility support. New exclusive protection against JSON and E4X hijacking. Anti-XSS filters performance [...]

  13. #13 Modern-Day Frame Busting With X-FRAME-OPTIONS And "This content cannot be displayed in a frame" Warnings says:

    [...] useful discussion on the issue can also be found in this post on [...]

  14. #14 » Google Talk Badges vs X-Frame-Options says:

    [...] frame) — or a blank one if you’re on Chrome — because Google is sending down a X-Frame-Option HTTP header with value SAMEORIGIN, allowing only pages served from to embed this [...]

  15. #15 Mike says:

    I've implemented X-Frame-Options on my website using some simple Apache config. See for information on how to do it.

Bad Behavior has blocked 729 access attempts in the last 7 days.