UI Redressing (Clickjacking)

Clickjacking loads a sensitive page (account settings, a "delete" or "authorize" button, an OAuth consent screen) inside a transparent or disguised iframe on an attacker's page, so a click the victim believes is landing on the attacker's own UI actually lands on the hidden page underneath. It's a framing problem, not an injection problem - the vulnerable page's HTML and logic are untouched; the only defect is that the server never told the browser it's not allowed to be framed. That makes it one of the few classes on this list that a black-box scanner can actually confirm directly, since the missing control is a response header, not a data-flow path that needs source access to trace.

• Account settings and profile-edit pages (email/password change, 2FA disable)
• Payment and subscription management pages
• OAuth/SSO consent and "authorize app" screens
• Admin action pages reachable from a known authenticated session (delete, approve, publish)
• Any page rendering a state-changing form with no CSRF token and no frame protection - the two combine into a one-click, fully invisible attack

• Load the target page in an <iframe> and check whether the browser renders it or refuses (blocked by X-Frame-Options / frame-ancestors)
• Overlay a decoy UI (a "claim your prize" button) positioned exactly over the iframe's real action button, using opacity: 0 or pointer-events tricks
• Scroll- or drag-jacking variants that reposition the invisible frame as the cursor moves, so any click on the page lands on the hidden target
• Double framing: a same-site page with a broken frame-buster still allows the attacker's page to frame it, defeating a client-side-only defense

• <iframe src="https://target/settings/delete-account" style="opacity:0;position:absolute;top:0;left:0"></iframe>
• A decoy button absolutely positioned to overlap the iframe's real submit button at the pixel level
• Content-Security-Policy: frame-ancestors and X-Frame-Options absent or set to a value that still allows framing (e.g. ALLOWALL, or ALLOW-FROM on a browser that ignores it)

This is a header-presence check, not a payload-injection check, which is why it's one of the more reliable black-box signals on this list. For every discovered page, request it directly and inspect the response headers: flag when both X-Frame-Options is absent (or set to a non-restrictive value) and the CSP has no frame-ancestors directive - either header alone is sufficient defense, so both must be missing to flag. Confidence is higher on pages that also render a state-changing form (account settings, delete/approve actions) since a purely informational page framed by an attacker has little to no impact. Cross-reference against pages requiring authentication, since clickjacking against a logged-out page is rarely exploitable.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• A missing frame-protection header on a purely static/marketing page (no login, no state-changing action) is a real but low-impact finding - don't over-score it the same as a missing header on an account-settings or payment page.
• Some frameworks set X-Frame-Options: SAMEORIGIN by default, which blocks third-party framing but still permits same-origin iframe embedding - that's a legitimate, intentional configuration for apps with same-origin iframe features (dashboards, embeds), not a finding.

Manual Testing Methodology

Here is a systematic approach to identifying UI Redressing (Clickjacking) vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For UI Redressing (Clickjacking) specifically, embed the target page in a locally-hosted iframe with reduced opacity or pointer-events layered over decoy content, and check whether it renders at all — the finding is confirmed by the frame loading successfully, not by anything payload-specific.

Compare the response against your baseline, looking specifically for whether the target page renders inside the iframe (absence of a frame-busting response or an appropriate X-Frame-Options/frame-ancestors header), and whether a sensitive action is reachable via a single click within that frame.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For UI Redressing (Clickjacking), a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

UI redressing, commonly called clickjacking, tricks a victim into clicking something on the target site they didn't consciously intend to click, by rendering that site in an invisible or disguised frame layered under attacker-controlled content. Because the victim's real, authenticated session performs the click, the resulting action is indistinguishable server-side from a legitimate user action.

The severity is entirely tied to what action gets clicked: clickjacking a "delete account" or "grant admin access" button is a serious finding, while clickjacking a "like" button is closer to a nuisance. Reports that demonstrate a specific, damaging action tend to be rated accordingly.

A close variant, drag-and-drop or cursor-jacking style redressing, extends the same underlying trick to multi-step or data-exfiltration interactions rather than a single click.

Prevention and Secure Coding

Preventing UI Redressing (Clickjacking) takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Frame-ancestors CSP. Send a Content-Security-Policy: frame-ancestors 'none' (or a specific allowlist of legitimate embedding origins) on every response that shouldn't be embeddable — this is the modern, flexible successor to X-Frame-Options and should be the primary control.

X-Frame-Options as a fallback. Send X-Frame-Options: DENY or SAMEORIGIN alongside the CSP for older clients that don't support frame-ancestors.

Apply it site-wide by default, not per-page. Set the header at the framework or reverse-proxy level so new pages are protected automatically, rather than remembering to add it to each one individually.

Frame-busting JS as defense-in-depth only. Client-side frame-busting scripts are a reasonable supplementary layer but are bypassable in ways header-based controls aren't — don't rely on them alone.