How do I install the Hunt Clickjacking skill?

Run npx skillmds@latest add elementalsouls/hunt-clickjacking in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Hunt Clickjacking safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: makes network calls, reads secrets. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Hunt Clickjacking?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Hunt Clickjacking free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Hunt Clickjacking?

elementalsouls (@elementalsouls) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Hunt Clickjacking by elementalsouls

Name: Hunt Clickjacking
Rating: 4.2 (5 reviews)
Author: elementalsouls

Hunt Clickjacking

Hunt Clickjacking — missing X-Frame-Options / CSP frame-ancestors lets an attacker embed the target page in an invisible iframe and trick victims into clicking buttons they cannot see (UI redressing). Targets: login flows, money transfers, account settings, OAuth confirmation pages. Confirm by fetching the page, then PROVE it frames in a real browser and a sensitive state-changing action survives the cross-site context (SameSite cookies / framebusting JS can defeat it) — header-absence alone is not a finding.

File contents

What is Clickjacking

Clickjacking (UI Redressing) lets an attacker load a target page inside a transparent iframe on a malicious site. The victim sees the attacker's decoy UI but clicks the hidden target UI beneath it. No JavaScript on the target is required.

Highest-value targets:

Login / authentication pages — force login with attacker credentials
Money transfer / checkout / "confirm payment" buttons
Account settings (email change, password change, 2FA disable)
OAuth / social-login "Authorize app" confirmation dialogs
Admin actions (delete, promote user, change role)

Protection Headers

Two mechanisms prevent framing:

X-Frame-Options: DENY              # strongest — blocks all framing
X-Frame-Options: SAMEORIGIN        # allows same-origin frames only
Content-Security-Policy: frame-ancestors 'none'     # CSP equivalent of DENY
Content-Security-Policy: frame-ancestors 'self'     # CSP equivalent of SAMEORIGIN

If NEITHER is present, the page is frameable from any origin.

How to Test

Header-absence is the trigger for investigation, not the finding. Two steps:

Step 1 — Header check (screening). Fetch the target page and inspect the response headers:

curl -sI https://target.example/account/transfer | grep -iE 'x-frame-options|content-security-policy'

If BOTH X-Frame-Options and CSP frame-ancestors are absent, the page is a candidate. If either is present and restrictive (DENY/SAMEORIGIN/frame-ancestors 'none'|'self'), stop — it's protected.

Step 2 — Prove it actually frames and clicks (required for a real finding). Build a minimal PoC and load it in a real browser:

<!doctype html>
<h1>Win a prize — click below</h1>
<iframe src="https://target.example/account/transfer"
        style="opacity:0.1;position:absolute;top:0;left:0;width:1000px;height:800px"></iframe>

Confirm ALL of the following, or it is not exploitable:

The page actually renders inside the iframe (no framebusting JS that blanks/redirects it — e.g. if(top!==self) breakout, or a Sec-Fetch-Dest/JS frame check).
The sensitive action still works while framed — critically, the action must succeed cross-site. If it relies on a session cookie set SameSite=Lax or SameSite=Strict (the modern default), the cookie is not sent on the cross-site framed request, and the clickjack fails. Verify the victim's authenticated state carries into the frame.
The target is a state-changing action (transfer, settings/email/password change, 2FA disable, OAuth authorize, admin action), not a read-only page.

Strategy: target the most sensitive action pages first — severity scales directly with what the victim is tricked into doing.

False Positives

Public, read-only pages (home/marketing) lacking frame protection are low/informational — no sensitive action to redress.
APIs and non-HTML endpoints (JSON, images) are not clickjacking targets.
Header-absence alone is NOT a finding. SameSite cookies, framebusting JS, or the lack of any sensitive framed action can each fully defeat it — which is why Step 2 is mandatory.

Proof Requirements

A valid clickjacking report shows: (1) the target page rendered inside an attacker-controlled iframe in a real browser, (2) a sensitive state-changing action reachable by a framed click while the victim is authenticated (cookies survive the cross-site context), and (3) a screenshot/recording of the overlay. Reporting missing headers with no working frame PoC is a documentation-quality issue, not a vulnerability.

---name: hunt-clickjackingdescription: Hunt Clickjacking — missing X-Frame-Options / CSP frame-ancestors lets an attacker embed the target page in an invisible iframe and trick victims into clicking buttons they cannot see (UI redressing). Targets: login flows, money transfers, account settings, OAuth confirmation pages. Confirm by fetching the page, then PROVE it frames in a real browser and a sensitive state-changing action survives the cross-site context (SameSite cookies / framebusting JS can defeat it) — header-absence alone is not a finding.--- ## What is Clickjacking Clickjacking (UI Redressing) lets an attacker load a target page inside a transparent iframe on a malicious site. The victim sees the attacker's decoy UI but clicks the hidden target UI beneath it. No JavaScript on the target is required. **Highest-value targets:** - Login / authentication pages — force login with attacker credentials - Money transfer / checkout / "confirm payment" buttons - Account settings (email change, password change, 2FA disable) - OAuth / social-login "Authorize app" confirmation dialogs - Admin actions (delete, promote user, change role) ## Protection Headers Two mechanisms prevent framing: ``` X-Frame-Options: DENY # strongest — blocks all framing X-Frame-Options: SAMEORIGIN # allows same-origin frames only Content-Security-Policy: frame-ancestors 'none' # CSP equivalent of DENY Content-Security-Policy: frame-ancestors 'self' # CSP equivalent of SAMEORIGIN ``` If NEITHER is present, the page is frameable from any origin. ## How to Test Header-absence is the **trigger for investigation, not the finding**. Two steps: **Step 1 — Header check (screening).** Fetch the target page and inspect the response headers: ``` curl -sI https://target.example/account/transfer | grep -iE 'x-frame-options|content-security-policy' ``` If BOTH `X-Frame-Options` and CSP `frame-ancestors` are absent, the page is a *candidate*. If either is present and restrictive (`DENY`/`SAMEORIGIN`/`frame-ancestors 'none'|'self'`), stop — it's protected. **Step 2 — Prove it actually frames and clicks (required for a real finding).** Build a minimal PoC and load it in a real browser: ```html <!doctype html> <h1>Win a prize — click below</h1> <iframe src="https://target.example/account/transfer" style="opacity:0.1;position:absolute;top:0;left:0;width:1000px;height:800px"></iframe> ``` Confirm ALL of the following, or it is not exploitable: - The page **actually renders inside the iframe** (no framebusting JS that blanks/redirects it — e.g. `if(top!==self)` breakout, or a `Sec-Fetch-Dest`/JS frame check). - The **sensitive action still works while framed** — critically, the action must succeed *cross-site*. If it relies on a session cookie set `SameSite=Lax` or `SameSite=Strict` (the modern default), the cookie is **not** sent on the cross-site framed request, and the clickjack fails. Verify the victim's authenticated state carries into the frame. - The target is a **state-changing action** (transfer, settings/email/password change, 2FA disable, OAuth authorize, admin action), not a read-only page. **Strategy:** target the most sensitive action pages first — severity scales directly with what the victim is tricked into doing. ## False Positives - Public, read-only pages (home/marketing) lacking frame protection are low/informational — no sensitive action to redress. - APIs and non-HTML endpoints (JSON, images) are not clickjacking targets. - **Header-absence alone is NOT a finding.** SameSite cookies, framebusting JS, or the lack of any sensitive framed action can each fully defeat it — which is why Step 2 is mandatory. ## Proof Requirements A valid clickjacking report shows: (1) the target page rendered inside an attacker-controlled iframe in a real browser, (2) a sensitive state-changing action reachable by a framed click while the victim is authenticated (cookies survive the cross-site context), and (3) a screenshot/recording of the overlay. Reporting missing headers with no working frame PoC is a documentation-quality issue, not a vulnerability.

Frequently asked questions