Quick answer: Clickjacking is when an attacker places a website you trust as an invisible layer over their own trap page and tricks you into performing an action on that hidden page without realizing it. You think you are clicking a button but you actually click a confirmation in the invisible layer (a money transfer, granting a permission, changing an account setting). The attack exploits that a site can be embedded inside another page in an iframe. The way to protect is in the site owner's hands and is simple: add HTTP headers (X-Frame-Options: DENY or Content-Security-Policy frame-ancestors) that prevent your site from being embedded in other pages. This single configuration stops almost all clickjacking attacks and is missing on many sites.

You trust a website, you click a button on it, but what you click is not the button you see. This is exactly clickjacking: the attacker makes a site you trust into an invisible layer and puts it over their trap, and while you think you are clicking something innocent you actually confirm a dangerous operation in the hidden layer. This article explains how clickjacking works and how, as a site owner, to protect your site against it.

How it works

Clickjacking exploits the browser feature that a web page can be embedded inside another page (with an iframe). The attacker prepares a trap page; on this page there is an attractive button saying, for example, Win the Prize. Right over this button, inside an iframe made invisible (transparent), they place a real site you trust (your bank, your social media) and align a dangerous button of that site (send money, grant permission) exactly where you will click. You think you clicked Win the Prize; in reality you confirmed the real operation in the invisible layer.

The power of the attack is that everything happens on the legitimate site; you are already logged into that site, so the operation happens with your authorization.

Why it is dangerous

Scenario Result
Banking confirmation Unknowing money transfer
Permission screen Granting authorization to an app
Social media Like, follow, share (likejacking)
Account setting Confirming email/password change
One click purchase Unintended order

The insidiousness of clickjacking is that the user makes no mistake; they click a site they trust, but their click is stolen. This is why defense is not with the user but in the site itself.

Protection: the site owner's responsibility

The good news: protection against clickjacking is in the site owner's hands and is technically simple. It is enough to tell the browser this page cannot be embedded inside other pages. You do this with one of two HTTP headers:

Method Setting Effect
X-Frame-Options DENY or SAMEORIGIN Prevents the page from being embedded in an iframe
CSP frame-ancestors 'none' or 'self' The modern, more flexible equivalent

The modern approach is the frame-ancestors directive of Content-Security-Policy; it precisely controls which sites (if any) can embed your page. For most sites, "frame-ancestors 'self'" or "'none'" is the right choice. These headers are part of the general set of HTTP security headers; we covered the others (HSTS, X-Content-Type-Options) in the context of SPF, DKIM, DMARC and email spoofing and general web security.

A vulnerability or a configuration gap

Clickjacking is usually not a code flaw but a configuration gap; that is, it comes not from doing something wrong but from never adding a protection. This is why clickjacking appears as a finding in many penetration tests: the site works, looks secure, but the iframe protection is missing. Such gaps are systematically detected during a web application penetration test. Adding it takes minutes but until it is added the site is an open target.

The KAOS and DSET approach

DSET assesses organizations' web applications against configuration gaps including clickjacking. Our local AI engine KAOS scans a site's HTTP security headers to detect missing X-Frame-Options or frame-ancestors protection, and reports every finding with a working proof, without false positives. The goal is to ensure a gap that can be closed in minutes is fixed before it gives an attacker an opportunity.

Frequently asked questions

What can I do against clickjacking as a user? Limited, because defense is mainly with the site owner. Still, keeping your browser up to date, being careful with tempting you won buttons on unfamiliar sites, and doing sensitive operations (banking) only in the official tab you entered directly reduce the risk. But the real protection comes from sites you trust adding iframe protection; this is a site owner responsibility.

Should I use X-Frame-Options or CSP frame-ancestors? Both prevent clickjacking but frame-ancestors is more modern and flexible; it precisely controls which sites can embed your page and replaces the old X-Frame-Options. The best approach is to use both together for broad browser compatibility: X-Frame-Options: SAMEORIGIN and CSP frame-ancestors 'self'. For most sites these two are enough.

My site is small, does clickjacking concern me? Yes. Clickjacking depends not on your site's size but on the operations done in it. Any site where users log in and do an operation (purchase, setting change, confirmation) can be a target. Moreover, adding the protection takes minutes and has no cost; there is no reason to skip such a cheap and effective measure.

Sources

To assess your web application against clickjacking and other configuration gaps, contact DSET. We provide web security consulting from our Ankara Hacettepe Teknokent laboratory.