Clickjacking and UI redressing
A real page can be embedded inside another site's invisible iframe, with fake UI drawn on top — the victim genuinely clicks a real button on the real, legitimate site the whole time, they just believe they're clicking something else entirely.
3 min read
The mechanism: an invisible iframe, with something else drawn on top
<!-- On attacker-site.com -->
<style>
iframe { opacity: 0.0001; position: absolute; top: 0; left: 0; z-index: 2; }
.fake-button { position: absolute; top: 300px; left: 400px; z-index: 1; }
</style>
<div class="fake-button">Click here to win a prize!</div>
<iframe src="https://real-bank.com/transfer?to=attacker&confirm=true"></iframe>
<!-- the iframe is positioned so its REAL "Confirm Transfer" button sits
EXACTLY on top of the fake "win a prize" button, but invisible -->The attacker's page renders the real, legitimate site (real-bank.com) inside an iframe, made nearly invisible with opacity, positioned precisely so the real site's genuine "Confirm" button lands exactly where the attacker's own fake, visible button appears to be. A victim sees "Click here to win a prize," clicks it, and their click actually lands on the real bank's real, invisible confirm button underneath — the click genuinely happens on the legitimate site, with the victim's own real, authenticated session (since the browser loaded real-bank.com for real, cookies and all), the victim just has no idea what they actually clicked.
Why this is a genuinely different attack from CSRF, despite a superficial similarity
CSRF: the browser AUTOMATICALLY sends a forged request with attached
cookies — the victim never sees or interacts with anything at all
Clickjacking: the victim GENUINELY, physically clicks something — the
attack tricks WHAT they believe they're clicking, not whether a request
gets sent automatically
CSRF (covered earlier in this domain) forges a request entirely automatically, with no victim interaction required at all — an <img> tag alone can trigger it. Clickjacking is structurally different: it requires the victim to genuinely click something, and its entire mechanism is deception about what that click actually does, since the real click really does land on the real site's real UI, just visually disguised as something else. Both end with an unintended action happening on a legitimate site using the victim's real session, but the actual mechanism triggering it is different.
The fix: preventing the page from being framed at all
X-Frame-Options: DENY
Content-Security-Policy: frame-ancestors 'none'
This is the exact same header covered in this domain's security-headers lesson, worth restating here specifically because it's the direct, structural fix for clickjacking: if the browser refuses to render real-bank.com inside any <iframe> at all, the entire attack has no invisible layer to hide behind in the first place — there's simply nothing to overlay a fake button on top of, since the real page can't be embedded at all.
Which pages genuinely need this protection, and which don't
Pages that perform a real, state-changing action (a transfer confirmation,
an account settings change, a "delete" button) are the real targets —
clickjacking's whole point is tricking a click into triggering something
consequential
A purely informational page with no state-changing action available has
much less to protect against here, though frame-busting headers are
cheap enough to apply broadly regardless
The pages genuinely worth protecting are ones with a real, single-click, state-changing action available — a confirm button, a delete button, a settings toggle — since clickjacking's entire value to an attacker is tricking exactly that kind of consequential click. A purely read-only, informational page has comparatively little for an attacker to gain by clickjacking it, though applying frame-denial headers broadly across an entire application is cheap and removes the need to reason carefully about which specific pages need it and which don't.
Further reading
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. How does clickjacking actually trick a victim into performing a real action on a legitimate site?
2. How is clickjacking structurally different from CSRF, despite both resulting in an unintended action on a legitimate site?
3. What's the direct, structural fix for clickjacking?