What Is Clickjacking? UI Redress Attacks Explained

Clickjacking is an attack that tricks a user into clicking something other than what they think they’re clicking, usually by layering an invisible or disguised iframe from a target site over a decoy page the user is actually looking at. The click lands on the hidden page, not the one the user sees — hence the alternative name, UI redress attack.

How the attack works

The attacker builds a normal-looking page — a game, a “click here to continue” button, a video player — and stacks an invisible iframe from the target site directly on top of it, positioned so the target site’s real, sensitive button lines up exactly with the decoy’s fake button. CSS does the work:

iframe {
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  opacity: 0.0001;
  z-index: 2;
}

The user sees a harmless-looking page. They see the decoy button. They click it. What actually receives the click is whatever’s rendered at that pixel in the invisible iframe underneath — a “delete my account” button, a “authorize this app” consent screen, a “transfer funds” confirmation. Because the click occurred inside the target site’s own iframe, on the target site’s own page, it carries the user’s real session cookie and looks, from the target server’s perspective, exactly like a legitimate click. This is why clickjacking is often discussed alongside CSRF: both exploit the fact that a browser will happily send authenticated requests the user didn’t consciously intend, though clickjacking does it by manipulating what the user sees rather than forging the request itself.

Real-world variants

Likejacking disguises a “Like” or “Follow” button from a social platform to farm engagement the user never meant to give.

Cursorjacking goes further and manipulates the visual position of the cursor itself, so the user believes they’re clicking one location while the actual click lands somewhere else entirely — a more sophisticated variant that defeats some naive defenses that only check click coordinates.

Cross-origin drag-and-drop attacks trick users into dragging content across an invisible iframe boundary, exfiltrating data the user thinks they’re just rearranging on a page.

All of these share the same root cause: the browser lets one origin’s content be embedded inside another origin’s page by default, and rendering doesn’t have to be honest about what’s actually receiving the interaction.

Defense: X-Frame-Options and CSP frame-ancestors

The primary defense is telling browsers your page should never be embedded in a frame at all, using one of two HTTP response headers.

X-Frame-Options is the older mechanism:

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

DENY blocks framing entirely; SAMEORIGIN allows framing only by pages on the same origin.

The modern replacement is the frame-ancestors directive of a Content Security Policy, which is more flexible — it can allow a specific list of trusted origins rather than an all-or-nothing choice:

Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.example

frame-ancestors supersedes X-Frame-Options where both are present and supported, but sending both is common practice, since X-Frame-Options still gets picked up by older clients that don’t evaluate frame-ancestors.

Defense: cookies and framebusting scripts

Setting the SameSite attribute on session cookies adds a second layer: a cookie marked SameSite=Strict or SameSite=Lax won’t be sent on many cross-site framed requests, which limits what an attacker’s iframe can actually do even if framing itself isn’t blocked. See our guide to cookie attributes for how SameSite interacts with HttpOnly and Secure.

Older sites sometimes rely on JavaScript “framebusting” code — if (top !== self) { top.location = self.location; } — to break out of a frame at runtime. This approach is weak and shouldn’t be your only defense: it can be disabled by an attacker who loads the page in a sandboxed iframe with scripts restricted, and it runs after the page has already loaded, leaving a window where the attack can still work. Header-based defenses are enforced by the browser before the page renders at all, which is why they’re the recommended approach and framebusting scripts are considered a legacy fallback at best.

Clickjacking and the same-origin model

Clickjacking is possible precisely because the same-origin policy restricts script access across origins but doesn’t, by default, restrict rendering one origin’s content inside another. An attacker’s page can’t read the DOM inside your iframe or steal your session token directly — same-origin policy still blocks that — but it can still get the user to click on it, which is enough for many attacks since the click itself is the exploit, not data theft.

That’s also why clickjacking defenses are opt-in and header-based rather than automatic: the platform has to assume framing might be legitimate (a payment widget embedded in a partner’s checkout page, for instance) and lets each site declare its own policy rather than banning framing outright.

The takeaway

Clickjacking hides a legitimate site’s interactive element inside an invisible iframe layered over a decoy page, so a user’s click lands somewhere they never intended. The fix is server-side: send Content-Security-Policy: frame-ancestors (and X-Frame-Options as a fallback) on any page with sensitive actions, so the browser refuses to render it inside someone else’s frame at all. Pair that with SameSite cookies to limit what a successful frame can even accomplish, and treat JavaScript framebusting as a last resort, not a primary defense.