Clickjacking (UI redress)
When it applies
A sensitive, state-changing page can be embedded in an <iframe> on an attacker site, and the
action needs only clicks (no CSRF token / re-auth). The attacker overlays their own UI so the
victim clicks the framed action unknowingly.
Why it works
Without X-Frame-Options: DENY/SAMEORIGIN or CSP frame-ancestors, the browser lets any site
frame the page. Making the frame transparent and positioning it under a decoy button turns the
victim's clicks into actions on the target in their authenticated session.
Method
- Check framability: load the target in
<iframe src="https://target/…">; if it renders (no framebusting), it's frameable. Inspect for missingX-Frame-Options/frame-ancestors. - Find a worthwhile action: one-click state change — delete account, change email, authorize OAuth, transfer, enable a setting.
- Build the PoC: transparent iframe (
opacity:0) over a decoy ("Click to win"), aligned so the victim's click lands on the target's button. Multi-step → chain frames/drag (classic UI redress). - Assess impact honestly — clickjacking on a trivial action is low; on ATO/authorization it matters.
Gotchas
SameSite=Lax/Strictcookies can break framed authenticated actions — verify the action still fires framed.- Modern browsers + CSP
frame-ancestorsusually block it; the finding is the missing protection + a real action. - Don't over-claim: needs victim interaction and a meaningful action to be more than informational.
Verify success
A working PoC page where a normal-looking click performs the sensitive action on the target in the victim's session (screen-record the overlay).
References
PortSwigger clickjacking labs; OWASP clickjacking defense cheat sheet.