About IFRAME and clickjacking

The world was a much simpler place to live. Designers and developers could integrate content from different sites whenever they wanted to. One IFRAME and ready. The imagination was the limit.

They were good times. They all lived happy and at peace, in a great global village where all were brothers and shared freely their sites.

That's when the clickjacking. The world as we knew it no longer exists and the free coexistence has become a distant memory.

ABBOT, Igor. "Ancient legends of the Web world"

All kidding aside, one thing is indeed: Clickjacking forever changed the behavior of the IFRAME tag in HTML pages. Explaining: the motivation for this post came from a thread of emails on the list of the VSTS product team. There, someone asked the following:

We make use of Jenkins to schedule various test executions. Today, I was thinking I could simply create a custom hub that would host the Jenkins site within an IFRAME within the hub in our VSTS Test account. However, quickly testing this idea out seems to show that I can't do that. Possibly due to some CORS limitations?
Is it possible to host an IFRAME in a custom hub in VSTS showing content from outside the VSTS account? If so, does someone have an example?

In other words: would there be any way to host an external page (in this case, a page of Jenkins) within the VSTS? You can imagine a lot of scenarios where this would be useful: Show builds of Jenkins, Sonar code analysis, SharePoint documentation. All straight into the VSTS Web interface.

Cool, huh? There's just one small problem:

Current versions of Jenkins have the X-Frame-Options headers set to disallow IFraming the Jenkins site for security reasons (. ..)

Don ' t allow iframing sites because you can use that for clickjacking.

Huh? I mean that sites do not allow more that make use of IFRAME? Everything to do with that of clickjacking?


Clickjacking is a technique used by malicious websites to trick users and force them to click on pages that they didn't want to. It's as if the malefactor was "hijacking" users clicks, redirecting them to a legitimate site to another malicious. Hence the name ("click hijacking").


Several sites have been victims of clickjacking in the past, such as Twitter and Facebook. Even the Flash Player had a hard time by using clickjacking techniques.

As the attack is based on the use of a transparent IFRAME containing a page of a legitimate site, those same sites could ask for browsers that were not open in an IFRAME. This way – preventing the opening of the page in an IFRAME-would be protected against this type of attack. Then came the HTTP header X-Frame-Options.

If you want to prevent your site from being open in an IFRAME on another website (including its Web sites, which are in the same domain), you must add the following header

X-Frame-Options: DENY

A compromise-free the use of IFRAME between pages on your site, but without allowing external use-can be obtained as follows:

X-Frame-Options: SAMEORIGIN

Finally, you can release the use of IFRAME to a specific site. That is, if you want an external site could use an IFRAME www.abc.com fictional to display a page from your site, you would place on your site the header:

X-Frame-Options: ALLOW-FROM: http://www.abc.com

You want to see how it works? Then create an HTML page with the code below.

    <iframe src="https://www.google.com" width="800" height="800"></iframe>

Now open it and see what happens:

IFRAME blocked by use of the X-Frame-Options header
IFRAME blocked by use of the X-Frame-Options header (click to enlarge)

IE: If you want to embed a page from any Web site or service that limits the iframing through tag X-Frame-Options, so it's in the dice. It's not going to work.


If you still want to, as in our example, using IFRAME to create a widget to TFS that displays a page of Jenkins, have two options:

Remove X-Frame-Options header

This is the most obvious solution, but also the most complicated. That's because she typically involves changing the source code of the original application or, at least, some setting on the Web server (Apache or IIS) that is serving the application.

CORS and jQuery

Another alternative is: instead of an IFRAME, pure and simple, is to use the load() method of jQuery. However, to load a page hosted on another site, you must first configure the permissions of CORS – that come with their own share of complication.


The truth is that there's no easy solution. The risk of clickjacking has made the use of IFRAME something overly complicated and that tends to fall more and more in disuse.

And you, dear reader? Have you come across this kind of situation? Do you have any idea/suggestion on how to deal with this? Leave your comment!


A hug,

Author: Igor Abade

Igor Abade V. Leite ([email protected]) is a Visual Studio ALM MVP (Microsoft Most Valuable Professional) since 2006. Speaker at various Software Development community events (TechEd Brasil, The Developers’ Conference, DevOps Summit Brasil, Agile Brazil, Visual Studio Summit, QCON among others), has also written articles in magazines and websites such as MSDN Brazil. Since March/2011 is one of the owners of Lambda3, a Brazilian consulting company specialized in ALM, software development and training. Visit his blog about VS ALM at http://www.tshooter.com.br/ and follow him on Twitter @igorabade.

Leave a Reply

Your email address will not be published. Required fields are marked *