Clickjacking - Hidden Clicks on Invisible Layers
About 2 min read
Clickjacking is an attack technique that overlays a transparent or invisible iframe on a legitimate page to trick users into performing actions they did not intend (clicking a button, submitting a form, and so on). Because users see only the legitimate page, they do not realize they are operating on a different site. It was named in 2008 by security researchers Jeremiah Grossman and Robert Hansen, and it became widely known as a sophisticated technique that combines social engineering with a technical attack.
How the Attack Works
The user thinks they clicked "gift," but they are actually executing "Delete account"
The attacker loads the target site in an iframe and makes it completely transparent with the CSS opacity: 0 property. Beneath it, the attacker places attractive content (a sweepstakes, a video play button, etc.) to lure the user into clicking. The click passes through the transparent iframe and reaches the target site, so if the user is already logged in to the target site, the action is executed with their privileges.CSRF is similar, but whereas CSRF forges the request, clickjacking differs in that it hijacks the user's own click action.
Variants and Derivatives
Overlays Facebook's "Like" button with a transparent iframe to make users unwittingly click "Like." It became hugely popular around 2010 and prompted Facebook to strengthen its countermeasures.
Shifts the displayed cursor position away from the actual pointer position to make users click somewhere they did not intend. It abuses the CSS cursor property.
Hijacks drag-and-drop operations to make users upload their local files to the attacker's server. It abuses the HTML5 Drag and Drop API.
Countermeasures
The basic defense against clickjacking is to prevent your own site from being embedded in another site's iframe.
X-Frame-Options header specifies DENY (deny all iframe embedding) or SAMEORIGIN (allow only the same origin). If you need more flexible control, use the CSP frame-ancestors directive.frame-ancestors 'self' is equivalent to SAMEORIGIN, and you can also add specific domains to an allowlist. Today, CSP frame-ancestors is the recommended approach, and X-Frame-Options is commonly used alongside it as a fallback for legacy browsers.
Common Misconceptions
There is a misconception that "you can prevent it by writing frame-busting code in JavaScript," but attackers can disable JavaScript execution using an iframe with the sandbox attribute, so JS-based countermeasures alone are insufficient. Always implement defenses at the HTTP header level. In addition, if an XSS vulnerability, an attacker may be able to bypass the headers and inject an iframe, so you must also implement XSS countermeasures through secure coding.
Real-World Use Cases
"A security audit revealed that the admin panel had no X-Frame-Options header set. An attacker could embed the admin panel in an iframe and trick an administrator into clicking a privilege-change button. We addressed it by adding CSP frame-ancestors and restricting iframe embedding across all pages."
Browser extension security is explained in detail in the browser extension security article, browser password management in the browser password safety article, and phishing protection in the phishing protection article.web security books on Amazon are also helpful for understanding the countermeasures.
Was this article helpful?