What is Clickjacking? A Practitioner's Definition

Definition

Clickjacking is a user-interface redressing attack in which an attacker places a legitimate website inside an invisible or misleading frame. The victim believes they are clicking one control, but their input activates another action on the framed site.

Prevent clickjacking by configuring the application to reject unauthorized framing. Content Security Policy (CSP) frame-ancestors is the primary control; X-Frame-Options provides useful backward-compatible protection.

Analyst’s Take: Start with the framing policy on authenticated and sensitive routes rather than treating the homepage as representative coverage. X-Frame-Options remains useful for legacy clients, but CSP frame-ancestors should define the approved embedding policy.

How it works

A typical attack uses an attacker-controlled page containing an <iframe> that loads a target application. The attacker modifies the frame’s position, opacity, or surrounding content so that a sensitive button sits beneath an apparently harmless one.

A victim might believe they are clicking a video play button while actually approving an account change, submitting a transaction, or granting a permission. If the victim is already authenticated to the target application, the browser may send the victim’s session cookies with the request.

Clickjacking does not usually require the attacker to read the framed page. The attack succeeds by controlling the visual presentation and relying on the victim’s normal clicks. Same-origin policy limits the attacker’s ability to inspect cross-origin content, but it does not automatically prevent the attacker from embedding that content.

The main defenses are:

1. Restrict which origins may frame the application. Use CSP frame-ancestors.
2. Provide a legacy fallback. Use X-Frame-Options: DENY or SAMEORIGIN where appropriate.
3. Protect state-changing actions. Require CSRF defenses, explicit confirmation, reauthentication, or step-up authentication for high-impact operations.
4. Use appropriate cookie settings. SameSite cookies can reduce some cross-site request risks, but they are not a standalone clickjacking defense.
5. Test sensitive routes. Security headers must be present on login, account, administration, payment, and workflow pages, not only on the homepage.

For broader application security testing guidance, see what is dynamic application security testing (DAST).

Technical Notes: Recommended headers

For an application that should never be framed, return:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

If the application must be embedded by a controlled parent site, use an explicit CSP allowlist:

Content-Security-Policy: frame-ancestors 'self' https://portal.example.com
X-Frame-Options: SAMEORIGIN

CSP frame-ancestors supports multiple origins and is the modern control. Do not use a broad wildcard unless embedding by arbitrary origins is an intentional and reviewed requirement. X-Frame-Options does not provide the same flexible allowlist behavior across browsers; values such as ALLOW-FROM are obsolete and should not be used as a modern solution.

At the reverse proxy or web server layer, a basic Nginx configuration might look like:

add_header Content-Security-Policy "frame-ancestors 'none'" always;
add_header X-Frame-Options "DENY" always;

The always parameter helps ensure the headers are returned on error responses as well. Validate the final response at the edge, because a proxy, CDN, application framework, or route-specific configuration may override or remove headers.

Technical Notes: Verify the protection

Use curl to inspect response headers:

curl -sSI https://app.example.com/account/settings

Look for both controls:

Content-Security-Policy: frame-ancestors 'none'
X-Frame-Options: DENY

Check more than one route:

for path in login account/settings admin transactions; do
  echo "== $path =="
  curl -sSI "https://app.example.com/$path" | \
    grep -Ei 'content-security-policy|x-frame-options'
done

A browser-based assessment should also attempt to load the protected page from an untrusted origin. Confirm that the browser blocks the frame and that normal top-level navigation still works. Pay particular attention to pages served through alternate hostnames, legacy applications, mobile web paths, and error handlers.

When you’ll encounter it

Clickjacking risk is highest when a web application performs meaningful actions through a single click or when users remain authenticated for long periods. Common targets include:

• Online banking, payments, and money transfers
• Account settings, password changes, and email updates
• Administrative consoles and cloud management portals
• Permission grants, OAuth consent, and API key creation
• File sharing, deletion, publishing, or workflow approval
• Internal business applications exposed to browsers or remote users

You may also encounter clickjacking during penetration tests, security reviews, bug bounty assessments, and compliance audits. A common finding is that an application protects the homepage but omits framing controls on authenticated routes or API-driven interfaces.

Not every framed application is automatically vulnerable. Some products intentionally support embedding in portals, dashboards, or partner applications. In those cases, document the approved parent origins and enforce them narrowly. Review whether embedded pages expose sensitive actions and whether the business requirement can be met with a read-only or dedicated integration instead.

Related terms

• UI redressing: The broader category of attacks that manipulate how a user interface appears or receives input. Clickjacking is a common form.
• Frame busting: Client-side JavaScript intended to break a page out of an iframe. It is weaker than response headers because scripts can be disabled, bypassed, or affected by browser behavior.
• CSP frame-ancestors: The preferred browser-enforced policy for controlling which origins may embed a page.
• X-Frame-Options: An older HTTP response header that supports DENY and SAMEORIGIN controls and remains useful for legacy clients.
• CSRF: Cross-site request forgery abuses a victim’s authenticated session to submit requests. CSRF tokens and SameSite cookies address request authenticity, while frame protections address deceptive visual interaction.
• SameSite cookies: Cookie attributes that restrict some cross-site cookie transmission. They complement, but do not replace, anti-clickjacking headers.
• CORS: A browser policy governing whether scripts can read cross-origin responses. CORS does not prevent a site from being framed and is not a clickjacking defense.

Clickjacking can also appear alongside broader application compromise indicators. Security teams reviewing suspicious activity may find it useful to understand what an indicator of compromise (IOC) is, although IOC analysis does not replace header testing.

Practical checklist

Start by checking the response headers on login, account, administration, payment, and workflow pages. Deny framing by default, document any approved parent origins, retain the legacy header where appropriate, and verify the final policy at the edge.

A password manager such as Try 1Password → can support secure credential practices for administrators and developers, but it does not replace CSP, X-Frame-Options, CSRF protection, or route-level security testing.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.