Clickjacking: An Overlooked Web Security Hole

Dingjie Yang

Last updated on: September 7, 2020

Clickjacking is an attack that tricks a web user into clicking a button, a link or a picture, etc. that the web user didn’t intend to click, typically by overlaying the web page with an iframe. This malicious technique can potentially expose confidential information or, less commonly, take control of the user’s computer. For example, on Facebook, a clickjack can lead to an unauthorized user spamming your entire network of friends from your account.

We’ve known about clickjacking, also called “UI redress attacks,” for years now, as they were originally described in 2008 by Robert Hansen and Jeremiah Grossman. There are countermeasures that web sites can implement to protect against clickjacking attacks, such as framebusters, the X-Frame Option and some client-side plug-ins that can be installed in the browser. However, recent studies have shown that web sites may not be taking this vulnerability seriously – or at least they aren’t attempting to protect their web sites from clickjacking.

How Secure are Web Sites?

Busting Frame Busting: a Study of Clickjacking Vulnerability on Popular Sites, written by Gustav Rydstedt and Elie Bursztein, et. al., describes research conducted in 2010 of framebusting practices of the Alexa Top 500 web sites. The study showed that at that time, only about 14 percent of the Alexa Top 500 web sites and 37 percent of Alexa Top 100 web sites were using framebusters to secure their web sites against clickjacking.

Note: The table on the right shows the percentage of Alexa Top  web sites using framebusting.
Alexa Top Web Sites Use Framebusting (%)
Top 500 14%
Top 100 37%
Top 10 60%

Table 1: Framebusting among Alexa top sites

Inspired by this research, I decided to carry out a survey to check how many web sites take this vulnerability into account and deploy countermeasures to prevent clickjacking. I wrote some short scripts to check whether web pages of the tested web sites could be framed in my scripts. If my script could run and frame the web pages of the test targets successfully, it indicated that no countermeasures were deployed, and clickjacking was possible. The survey polled a range of Alex Top 10 web sites, Top 20 bank web sites and 5 popular open source web applications (Joomla, wordpress, phpbb, Drupal, Gallery).

Polled Category Protected Targets (%)
Alexa Top 10 web sites 70%
Bank Top 20 web sites 30%
Popular Open Source Web App 20%

Table 2: Usage of clickjacking countermeasures

From the table listed above, it can be concluded that many web sites provide absolutely no countermeasures against possible clickjacking attacks, even today, two years after 2010 study. This absence of sufficient protection is surprising since some of the web sites require a secure environment, such as banks providing online banking services.

So Why Aren’t Web Sites Taking Measures to Protect Against Clickjacking?

There could be many answers to this question, but I think three main factors contribute to ignorance of clickjacking vulnerabilities in web sites.

1. Clickjacking is not considered a serious issue because it is hard to manipulate.

I believe this is the most common reason. Some web developers consider clickjacking lower risk since it is harder to get sensitive information from an end-user, as compared with other attacks like XSS and SQL injection. However, the clickjacking attacks on Facebook in 2010 showed that harm is done even by sending spam to everyone in your address book.

Also, when a web site is vulnerable to clickjacking, it is possible for the attacker to disable cross-site request forgery (CSRF) token protection, which protects against CSRF attacks that trick browsers into doing things without the user’s knowledge or permission.

2. Countermeasures for clickjacking are not reliable.

Many countermeasures have been described that help web users protect against clickjacking attacks. But currently the only way that could completely prevent clickjacking attacks is to use a web browser like Lynx, a pure text-based web browser that doesn’t support JavaScript. Not only is Lynx outdated, but it’s hard to imagine a modern web site user experience without the use of JavaScript.

According to Robert Hansen, one of the first people to discover this vulnerability, “the combination of Firefox and NoScript, an extension that blocks JavaScript, Flash and Java content, would keep you safe from ‘a very good chunk of issues, 99.99% at this point’.” But again, the trade-off is a diminished user experience because JavaScript is blocked.

3. Lack of awareness

Because clickjacking is a relatively new malicious technique, the damage caused by this vulnerability is not widely known.

What could a web site administrator do to protect against clickjacking attacks?

In general, there are two popular methods that could be easily implemented to protect against clickjacking vulnerabilities: the first one is to apply a JavaScript framebuster into your web pages; the other one is to add X-FRAME-OPTIONS into the response header.

A framebuster is a piece of JavaScript code that prevents a web page from being rendered within a frame. There are many variations of framebusters in use in different web sites. As recommended by the OWASP community, the most reliable framebuster is:

<style> body { display : none;} </style>

if (self == top) {
  var theBody = document.getElementsByTagName('body')[0]; = "block";
} else {
  top.location = self.location;

X-FRAME-OPTIONS is a browser-based defense method. In order to bring the X-FRAME-OPTIONS protection into effect, Web developers should send a HTTP header named X-FRAME-OPTIONs on HTML responses. There are two options for X-FRAME-OPTIONS, the first one is DENY, which prevents the page from rendering if it is framed; the other one is SAMEORIGIN, which prevents the page from rendering only if the origin of the top level-browsing-context is different from the origin of the content containing the X-FRAME-OPTIONS directive.

Since all the major browsers have adopted the X-FRAME-OPTIONS and it is easier to implement than framebusters, and is therefore a good choice.

Neither X-FRAME-OPTIONS nor framebusters have proven to be 100 percent effective, but they significantly reduce the risk of clickjacking. It is definitely worth implementing them into your web sites if your web sites are running without any protection against clickjacking attacks.

Show Comments (4)


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

  1. Dingjie, thanks for this article. We have found in the past 6 months that auditors and assessors have a new focus on click-jacking as a High-risk threat. When pressed, several concerned parties have told us they see more REPUTATIONAL risk than security risk from a click-jacking attack.

    We have had to go back to vendors with auditor findings to ask for enhanced click-jacking protection in their products. Most do not see click-jacking as a significant threat, and lean towards adding the X-FRAME-OPTIONS headers and calling it "good". The auditors typically want script-based protection as well, so it can be a bit of a battle to implement a 'fix'.

    Lastly, a small typo in the article —

      "In order to bring the X-FRAME-OPTIONS protection into effect, Web developers should send a HTTP header named X-FRAME-OPTION on HTML responses."

      should read "X-FRAME-OPTIONS" — you missed the trailing "S" on the bolded mention.

    1. Hi pejacoby , thank you for reporting the typo. It has been amended. I agree with the auditors. It would be double check if the script-based frame busters could be added. The X-FRAME-OPTIONS are not effective for some old version browsers. It means that the users of web sites using X-FRAME-Options to protect from Clickjacking could still be harmed if they are using some old version browser in which X-FRAME-OPTIONS are not adopted.

      It is in our expectation that most vendors treat Clickjacking as Reputational risk rather than a significant security threat. I am writing another articles about exploiting XSS vulnerability by using Clickjacking attack against a popular open source web application. I hope it would promote some alert for Clickjacking vulnerability.

  2. Dear Dingjie,

    Please note that we using qualys to scan our website and from the result we see the below two QIDs:

    150124 Clickjacking – Framable Page
    150081Clickjacking – X-Frame-Options header is not set

    we implement X-FRAME-OPTIONS and set the value to sameorigin , but after re scanning the above vulnerabilities still present.

    appreciate your advise

    1. Hi tareq,

      Could you please check whether you have duplicated x-frame-options header in the response header? If there are duplicated x-frame-options in the header, WAS will flag both QID 150081 and QID 150124. I mentioned a common implementation error at another blog

      If there is only one single x-frame-options item in the response header, please contact our support team so that we could troubleshoot the issue.