Clickjacking

Clickjacking loads your real, logged-in page inside an invisible frame on the attacker’s site, then overlays a decoy — a game, a “claim prize” button — exactly over a sensitive control. You think you are clicking the decoy; the click lands on the framed page, performing a real action as you. The defence is to tell the browser who, if anyone, may frame the page.

What is the vulnerability?

• No defence. The page sets neither X-Frame-Options nor CSP frame-ancestors, so any site frames it.
• JS frame-buster only. The page tries to break out of frames in JavaScript (if (top != self) ...). An attacker loads it in a sandboxed iframe, which cannot navigate the top window, so the buster never fires.
• Partial / obsolete coverage. The main path is protected, but a legacy path doing the same action uses the obsolete X-Frame-Options: ALLOW-FROM, which modern browsers ignore.

Why does it happen?

Framing defence is a header the browser must enforce, but it is easy to forget on some paths, to attempt in page JavaScript instead, or to write with a directive browsers dropped years ago.

How do you stop it?

Send CSP frame-ancestors 'none' (or 'self') on every response that can perform or reveal something sensitive — by default, not per page — and add X-Frame-Options: DENY for old browsers. Never rely on a JavaScript frame-buster, and never use ALLOW-FROM.

The three labs below walk this: frame an undefended page, neutralise a frame-buster with a sandbox, and frame a legacy path with a dead header.