Contact Us

What Is Clickjacking?

In this post, we discuss the concept of 'Clickjacking' and how to prevent it.

“Click what now“? Clickjacking is a generally misunderstood security vulnerability that is often difficult to explain and understand. The attack itself has been around for some time now; the term comes from a portmanteau of the words “click” and “hijacking.” But what is clickjacking? How does it pose a risk? More importantly, how do you defend against it? Let us take a look.

Clickjacking generally refers to a type of attack in which a user is tricked into clicking on actionable content on a hidden website. This is usually done via an intermediary website. Consider the below image:

Clickjacking illustration
Clickjacking (Image source – OWASP)

The victim visits the attacker’s website with the intent of communicating with the visible user interface, but unintentionally interacts with the secret tab. A hacker may use the hidden page to trick people into doing something they didn’t want to do by strategically placing hidden elements on the web page.

Now we understand the concepts. Let’s actually see what this might look like in the wild. We will be using to demonstrate how a website (which offers no protection against Clickjacking) can be used.

The below image shows the website being rendered in an IFRAME on the website. To demonstrate the Proof of Concept. A “Click here” button is overlayed ontop of the website.

So now we understand what clickjacking is. How do we actually defend against it? In order to resolve the issue of Clickjacking, we must first understand what is causing it. Essentially what’s happening here is the website is allowing a third-party website to embed it into an IFRAME, thus making clickjacking possible. Now could resolve this issue fairly easily.


Disallowing this (Clickjacking) can be done through the appropriate HTTP Security Headers. These headers will instruct the browser not to render the website in an IFRAME.

We can either use the ‘Content-Security-Policy‘ security header, or ‘X-Frame-Options‘.

Below we can see various configurations of the Content-Security-Policy header. Either of them will stop this attack from occurring in most cases.


  1. Content-Security-Policy: frame-ancestors ‘none’ – Set this if you want to disallow every domain from embedding your site in an Iframe.
  2. Content-Security-Policy: frame-ancestors ‘self’ – Set this if you want to disallow every domain from embedding your site except the site itself (Hence ‘self’).
  3. Content-Security-Policy: frame-ancestors uri – Set this if you want to allow a specifc uri to embed your site in an Iframe and dissallow all the others.


Alternatively the X-Frame-Options header can be used.

X-Frame-Options: DENY – The page is not allowed to be displayed in a frame, regardless of what origin requested it.

X-Frame-Options: SAMEORIGIN – The page can only be displayed in a frame from the same origin as the website.

Let’s take a look at a target site which does implement an adequate framing policy, below you will see our breaches database stopping the third party site from rendering it in an IFRAME.

If we take a peak at the RAW HTTP HEADERS, we can see that implements the X-Frame-Options security header.

“HTTP/1.1”: “200 OK”,
“server”: “nginx/1.14.0 (Ubuntu)”,
“date”: “Sun, 07 Mar 2021 20:51:38 GMT”,
“content-type”: “text/html; charset=utf-8”,
“transfer-encoding”: “chunked”,
“connection”: “close”,
“referrer-policy”: “same-origin”,
“x-frame-options”: “SAMEORIGIN”,
“strict-transport-security”: “max-age=86400”