Clickjacking Explained: How to Test and Prove Real Impact

Clickjacking Explained: How to Test and Prove Real Impact

Clickjacking (UI redressing) tricks a user into clicking something different from what they think. The attacker loads a target page in an invisible frame, floats a decoy on top, and the victim's click lands on a sensitive control — “delete account,” “authorize app,” or “transfer.”

It is beginner-friendly to find but frequently reported without impact. The skill is proving a click actually does something meaningful.

How the attack works

1. The attacker page embeds the target in an iframe.
2. CSS makes the frame transparent and positions it over a decoy button.
3. The victim clicks the decoy; the click hits the framed sensitive action.

For this to work, the target must be framable — it must not block embedding.

Check framability first

Look at the target's response headers:

• Missing X-Frame-Options and no framing rules in Content-Security-Policy: frame-ancestors
• frame-ancestors that allows your origin (too permissive)

If either X-Frame-Options: DENY/SAMEORIGIN or a strict frame-ancestors is present and enforced, the page is protected and clickjacking usually is not valid.

Build a safe proof-of-concept

A clean PoC:

1. Create a simple HTML page that frames the sensitive target page.
2. Reduce frame opacity so you can align a decoy element over the real button.
3. Record that clicking your decoy triggers the framed action using your own test account.

Never frame the target to trick real users. Demonstrate on yourself and capture the alignment.

Prove impact, not just framing

Triagers reject “the page can be framed” with no consequence. Show a sensitive, state-changing action behind one or two clicks:

• Deleting or transferring something you own
• Changing account settings or granting an OAuth app
• Toggling a security control

If the only framable pages are static or read-only, impact is low and severity should reflect that.

Common false positives

• Framable pages with no meaningful single-click action
• Actions that require typing or confirmation the framing can't supply
• Protections present but you tested the wrong subdomain

Report structure

Include the missing/weak headers, your PoC HTML, a screenshot of the aligned decoy, and the sensitive action performed. Recommend Content-Security-Policy: frame-ancestors 'self' (or a strict allowlist) plus X-Frame-Options for legacy clients.

Defensive checklist

• Set Content-Security-Policy: frame-ancestors 'self' on sensitive pages.
• Keep X-Frame-Options: SAMEORIGIN for older browsers.
• Require confirmation or re-authentication for destructive actions.
• Avoid single-click irreversible actions where possible.
• Test framing protection on every subdomain, not just the apex.

Clickjacking is easy to demonstrate and easy to overclaim. Focus on framable, sensitive, single-click actions and your reports will stand out from the noise.

Original Bugflare guide informed by OWASP clickjacking guidance.