Hunt Clickjacking

Clickjacking Assessment guides validation of UI redressing, where a decoy interface causes a user to click a target page loaded in a frame. A target can be affected without running attacker JavaScript on the target itself. The workflow begins with protection headers and continues to browser evidence; a missing header is an investigation trigger rather than sufficient proof of a vulnerability.

The header screen considers X-Frame-Options and the Content-Security-Policy frame-ancestors directive. DENY and frame-ancestors 'none' block framing, while SAMEORIGIN and frame-ancestors 'self' restrict it to the same origin. A restrictive setting ends the candidate workflow described in the skill. When protection is absent, the next question is whether the page actually renders in a real browser frame. Framebusting JavaScript or a frame-specific check may prevent that behavior even when headers are missing.

Validation also checks whether an authenticated sensitive action still works in the cross-site context. Session cookies with SameSite=Lax or SameSite=Strict can prevent the authenticated state from carrying into the frame. The workflow therefore requires evidence of the session state, not merely a visible login page or successful page load. The target action must change state, such as account settings, payment confirmation, OAuth authorization, or an administrative operation.

Use this material within a bug-bounty or penetration-test engagement that explicitly permits assessment of the named target. Written authorization and scope are prerequisites. The user must identify the exact resource, confirm authorization, inspect the proposed commands and their effects, and explicitly confirm before target probing or active actions. Without that confirmation, work remains read-only and defensive. A sandbox, disposable virtual machine, or controlled lab is preferred.

Public marketing pages with no sensitive action are low or informational candidates. JSON APIs, images, and other non-HTML endpoints are outside the described clickjacking target class. Header absence by itself must not become a vulnerability report. Browser defenses, cookie behavior, and the absence of a sensitive action can defeat the proposed issue.

Inputs include the authorized target list, permitted scope, response headers, and browser observations. The provided read-only example illustrates consulting the engagement brief:

# Read-only first step; confirm scope before anything active.
cat scope.txt  # target list from the authorized engagement brief

A valid report shows the target rendered inside a controlled frame, a sensitive action reachable while the authenticated state survives, and a screenshot or recording of the overlay. Missing-header documentation without a working browser demonstration falls below that evidence requirement.

This is a documentation-only import. Executable helpers, engines, commands, and research assets from upstream are not bundled. Finding validation goes through triage-validation and reporting through report-writing, with additional tooling obtained when needed.