Skip to main content
Application Security Standards
Category: Attack Techniques

Clickjacking

Also known as: UI Redress Attack, UI Redressing, User Interface Redress Attack
Simply put

Clickjacking is a type of attack where a user is tricked into clicking on something different from what they intended, typically because a malicious or hidden element is layered on top of a legitimate-looking webpage. An attacker may embed a trusted site inside a transparent frame so that the victim believes they are interacting with familiar content while actually triggering unintended actions. The deception relies on visual manipulation rather than exploiting code vulnerabilities directly.

Formal definition

Clickjacking is a client-side interface-based attack in which an adversary renders a target webpage, typically via an HTML iframe, as a transparent or opaque layer positioned over attacker-controlled content. When a victim interacts with the visible page, their clicks are intercepted by the concealed layer and directed to actionable elements on the framed target site, such as buttons or links, without the victim's knowledge or consent. The attack exploits the browser's willingness to render cross-origin framed content and requires no compromise of the target server. Mitigations are applied at the HTTP response level, commonly through frame-blocking directives such as the X-Frame-Options header or the Content Security Policy frame-ancestors directive, which instruct compliant browsers to restrict or deny framing of the protected resource.

Why it matters

Clickjacking represents a meaningful threat to web application users because it subverts trust rather than exploiting a technical code flaw. A victim may believe they are interacting with a familiar, legitimate interface while their clicks are silently redirected to hidden elements on a framed page, potentially triggering account changes, purchases, permission grants, or social media actions without their awareness or consent. Because the deception occurs entirely in the browser and requires no server-side compromise of the target site, it can be difficult for users to detect through normal behavioral cues.

The attack class is particularly relevant because its mitigations are straightforward to implement at the HTTP response level, yet many web applications still omit the necessary headers. The X-Frame-Options header and the Content Security Policy frame-ancestors directive are both well-established controls that instruct compliant browsers to refuse to render a page inside a frame from an unauthorized origin. When these controls are absent, any attacker who can serve a webpage to a victim may be able to construct a clickjacking scenario targeting that application. This makes the absence of framing controls a recurring finding in security assessments of web applications.

Who it's relevant to

Web Application Developers
Developers building web applications need to understand clickjacking because the primary defense, configuring appropriate HTTP response headers such as X-Frame-Options or the Content Security Policy frame-ancestors directive, is implemented at the application or server level. Omitting these controls leaves users of the application exposed to interface-based redress attacks even when the application's own code contains no exploitable vulnerability.
Security Engineers and Architects
Security engineers and architects are responsible for defining baseline security headers as part of application hardening standards. Clickjacking mitigations are typically addressed at the policy level, specifying which origins, if any, are permitted to frame a given resource. Architects designing applications that involve sensitive user actions, such as payment confirmation, permission grants, or account settings, should treat framing controls as a standard requirement rather than an optional enhancement.
Penetration Testers and Application Security Assessors
Clickjacking is a commonly checked item in web application security assessments. Testers typically verify whether framing protections are present and correctly configured in HTTP responses. It is worth noting that the presence or absence of these headers can be confirmed through static analysis of HTTP responses, but confirming actual exploitability in a specific context may require verifying that the target functionality is accessible to authenticated users in a frameable state.
End Users
End users are the direct targets of clickjacking attacks. Because the deception relies on visual manipulation rather than malware or credential theft, users typically have limited ability to detect an attack in progress through normal browsing behavior. User awareness of the technique may help in some contexts, for example, recognizing suspicious or unexpected pages, but the most effective protections are implemented by application owners rather than users themselves.

Inside Clickjacking

Transparent Overlay
A hidden or invisible iframe or element positioned over a legitimate page element, causing the user's click to register on the concealed content rather than the visible interface.
Framing
The act of embedding a target page within an attacker-controlled page using an iframe, which is the core mechanism enabling clickjacking attacks.
X-Frame-Options Header
An HTTP response header that instructs browsers to restrict or deny rendering of a page within a frame, supporting values such as DENY and SAMEORIGIN to control framing behavior.
Content-Security-Policy frame-ancestors Directive
A CSP directive that specifies which origins are permitted to embed a page in a frame or iframe, offering more granular control than X-Frame-Options and superseding it in modern browsers.
UI Redressing
A broader category of attack encompassing clickjacking, in which the visual presentation of a page is manipulated to deceive users into interacting with content other than what they believe they are clicking.
Framebusting Script
A client-side JavaScript technique intended to prevent a page from being loaded inside a frame, though this approach is considered unreliable due to known bypass methods in older browsers.
User Interaction Hijacking
The outcome of a successful clickjacking attack, in which a user's intended action such as a button click or form submission is redirected to trigger an unintended operation on the target application.

Common questions

Answers to the questions practitioners most commonly ask about Clickjacking.

Does X-Frame-Options fully prevent all forms of clickjacking?
X-Frame-Options provides meaningful protection against most clickjacking scenarios but is not a complete solution on its own. It is superseded by the Content Security Policy frame-ancestors directive, which offers more granular control. Some older or non-compliant browsers may not enforce X-Frame-Options consistently, so relying on it as the sole control is not recommended.
If my site uses HTTPS, am I protected against clickjacking?
No. HTTPS protects data in transit but does not prevent clickjacking. Clickjacking works by framing your page inside an attacker-controlled page, which is a presentation-layer attack. Transport encryption has no effect on whether a browser will allow your page to be embedded in an iframe on a malicious site.
How do I implement Content Security Policy frame-ancestors to prevent clickjacking?
Add a Content-Security-Policy response header that includes the frame-ancestors directive. To block all framing, use 'frame-ancestors none'. To allow framing only by your own origin, use 'frame-ancestors self'. To allow specific trusted origins, list them explicitly, for example 'frame-ancestors https://trusted.example.com'. This directive is evaluated by the browser and overrides X-Frame-Options in browsers that support CSP Level 2 and above.
Should I use X-Frame-Options or Content Security Policy frame-ancestors, or both?
The recommended approach is to use both headers for defense in depth. The Content Security Policy frame-ancestors directive is the modern standard and takes precedence in browsers that support it. X-Frame-Options provides a fallback for older browsers that do not support CSP. Setting both headers ensures broader compatibility without meaningful conflict, provided the policies are aligned in intent.
Can framebusting JavaScript replace header-based clickjacking protections?
Framebusting scripts, which attempt to break out of frames using JavaScript, are generally considered an unreliable control. They can be bypassed through techniques such as the sandbox attribute on iframes, which can block script execution within the framed page. Header-based controls such as Content Security Policy frame-ancestors and X-Frame-Options are enforced by the browser at the HTTP level and are significantly more reliable than script-based approaches.
Which types of pages or functionality should be prioritized when implementing clickjacking protections?
Pages that expose authenticated actions, state-changing operations, permission grants, financial transactions, or sensitive configuration changes should be treated as highest priority. These are the targets most commonly exploited in clickjacking attacks because an attacker can trick a logged-in user into performing an unintended action. Pages that serve purely informational content to unauthenticated users carry lower risk, though applying protections broadly is typically the simpler and more maintainable approach.

Common misconceptions

CSRF tokens protect against clickjacking.
CSRF tokens protect against cross-site request forgery by validating request origin, but they do not prevent clickjacking. In a clickjacking attack, the user is genuinely interacting with the target page, so any CSRF token present in the embedded form is submitted legitimately, making CSRF defenses ineffective against this attack class.
Framebusting JavaScript is a reliable defense against clickjacking.
Framebusting scripts can typically be bypassed through techniques such as sandbox attributes on iframes or browser-specific behaviors, particularly in older environments. Server-side header-based controls such as X-Frame-Options or the CSP frame-ancestors directive are considered more reliable defenses.
Clickjacking only affects pages with sensitive actions, making low-risk pages safe to leave unprotected.
Attackers may chain clickjacking with other vulnerabilities or use seemingly low-risk interactions as steps in a multi-stage attack. Applying framing controls consistently across an application is recommended rather than limiting protections only to pages identified as high sensitivity.

Best practices

Set the X-Frame-Options response header to DENY or SAMEORIGIN on all application pages, not only those considered sensitive, to prevent unauthorized framing across the application.
Prefer the CSP frame-ancestors directive over X-Frame-Options for modern browser environments, as it provides more granular origin control and is the recommended long-term approach where browser support allows.
Avoid relying on framebusting JavaScript as a primary defense, as it is subject to bypass in various browser configurations. Use it only as a supplementary measure alongside server-side header controls.
Audit Content Security Policy configurations regularly to confirm that frame-ancestors is explicitly set and that wildcard or overly permissive values have not been introduced through policy changes or third-party integrations.
Include clickjacking protection headers in security testing checklists and automated scanning pipelines so that missing or misconfigured headers are flagged during development and pre-release validation.
When a legitimate use case requires controlled third-party framing, use the frame-ancestors directive to allowlist only the specific trusted origins rather than disabling framing protections entirely.