Clickjacking, more formally called a UI redress attack, is one of the more elegant ideas in web security precisely because it breaks nothing technical. The target site loads correctly. The session is genuine. The button does exactly what it's supposed to do. The only thing the attacker manipulates is which surface your click lands on — and they do it with two CSS properties and an iframe.
The term dates to 2008, when researchers Jeremiah Grossman and Robert Hansen described how a transparent overlay could hijack user clicks. In the years since, the same trick has been used to harvest social-media "likes," toggle webcam permissions, drain accounts, and grant app authorizations — anywhere a single deliberate click carries weight.
The Mechanic: Two Layers, One Cursor
A clickjacking page has two layers stacked on top of each other:
- The decoy — what you see. A game, a prize wheel, a "play video" button, an enticing call to action.
- The target — what you actually interact with. The real, authenticated page (your bank, a settings panel, an OAuth consent screen) loaded inside an
<iframe>, positioned over the decoy and made invisible withopacity: 0.
The attacker aligns the two so that the target's sensitive button sits exactly where the decoy invites you to click. Your cursor hovers over the visible bait; your click passes through to the invisible real button underneath. Because you are genuinely logged into the target site in another tab or session, the action carries your full authority.
Nothing looks wrong. There's no fake login form to scrutinize, no suspicious URL in an address bar you can see — the dangerous frame is invisible and the visible page may be a perfectly real, harmless-looking site. Your judgment isn't being fooled; your input is being redirected.
The Family of Variations
Once you grasp the core idea — misdirecting input toward a hidden surface — the variants follow naturally:
Likejacking
An early, infamous form: a hidden social-media "Like" or "Share" button floated under a tempting decoy. Each tricked click silently amplified content or a page to the victim's network. Low stakes individually, but it spread spam and scams at scale.
Cursorjacking
The attacker hides the real cursor and draws a fake one offset by a few pixels. You aim the decoy cursor at something safe; your true click lands elsewhere. It defeats the "I clicked exactly where I meant to" intuition.
Drag-and-drop and keystroke variants
More advanced versions trick you into dragging text into a hidden field, or typing into an invisible input — useful for extracting data or filling sensitive forms. The principle is identical: the visible interface and the active interface are not the same thing.
How Clickjacking Differs From Its Cousins
It's easy to lump clickjacking together with other web attacks, but the distinction is sharp and worth holding onto:
| Attack | What it manipulates |
|---|---|
| Clickjacking | Where your real click lands — a deliberate action you take, redirected to a hidden but genuine page. |
| CSRF | Forges a request directly using your session — no click needed at all. |
| Phishing | A fake page that imitates a real one to harvest what you type. |
| XSS | Injects attacker code that runs inside the trusted page itself. |
Clickjacking is the only one that needs a real, authentic target page — that's the whole point. It launders the attacker's intent through your own genuine interaction with a site you trust.
The Defense: Refuse to Be Framed
Because clickjacking depends on loading the target site inside an attacker's iframe, the fix is for the target to forbid being framed by foreign origins. Two headers do this:
Content-Security-Policy: frame-ancestors
The modern, authoritative control. A site sends Content-Security-Policy: frame-ancestors 'none' to forbid framing entirely, or frame-ancestors 'self' to permit only its own pages to embed it. This is part of the same Content Security Policy mechanism that locks down other resource loading, and it's flexible enough to allow a specific trusted partner origin if needed. When present, it supersedes the older header below.
X-Frame-Options
The legacy header, with two practical values: DENY (never frame this page) and SAMEORIGIN (only same-origin pages may frame it). It's widely supported and still worth sending for older browsers, but frame-ancestors is the one to rely on going forward.
Send frame-ancestors 'self' (or 'none') on every page that performs a sensitive action, keep X-Frame-Options: SAMEORIGIN as a fallback, and never assume a page is "too boring to frame." If a click on it does anything meaningful, it's a target.
Defense-in-depth measures help too: requiring a second confirmation step for high-stakes actions, and pairing SameSite cookies with framing protection so that even a framed page can't carry a fully authenticated session from a cross-site context.
What Users Can Do
Clickjacking is fundamentally a server-side problem to fix, but you're not powerless. Be suspicious of pages that ask you to click through arbitrary "rewards," especially while you have a sensitive account open elsewhere. Browser script blockers that prevent unexpected framing add a layer of protection. And the oldest advice still holds: don't stay logged into financial or administrative accounts in a tab you've forgotten about while you browse the wider web.
The unsettling thing about clickjacking is that your senses report everything is fine. The interface you see is real, your click is real, the result is real — only the connection between them was forged.
That's the broader lesson it teaches, and one that shapes how we build interfaces at Haven: a secure system has to protect not just the data and the session, but the integrity of the user's intent. An action should only happen when the person actually meant for it to — and the design should make that meaning hard to hijack. It's the same principle that motivates clear, deliberate confirmation flows wherever a tap really matters.