Clickjacking
Clickjacking is a visual deception attack where a malicious website places transparent iframes over visible content, tricking users into clicking hidden elements that perform unintended actions on a target site.
Understanding Clickjacking
Clickjacking, also known as UI redressing, works by loading a target website in an invisible iframe overlaid on a malicious page. The attacker positions the iframe so that when the user clicks what they believe is a button on the visible page (like "Play Video" or "Claim Prize"), they actually click a hidden button on the target site — such as "Delete Account," "Transfer Funds," or "Grant Permission."
The attack exploits the fact that browsers execute clicks based on the element under the cursor, even if that element is invisible. The target website receives a legitimate, authenticated request from the user's browser (with valid session cookies), making it indistinguishable from an intentional action.
Variants include likejacking (forcing Facebook likes), cursorjacking (making the visual cursor position differ from the actual position), and drag-and-drop clickjacking (manipulating users into dragging sensitive data into an attacker-controlled element). Multi-step clickjacking can guide users through several clicks to complete a complex action like changing an email address and confirming the change.
Prevention relies on two HTTP headers. X-Frame-Options: DENY prevents the page from being framed entirely. X-Frame-Options: SAMEORIGIN allows framing only by the same domain. The modern replacement is the Content-Security-Policy frame-ancestors directive, which provides more flexible control: frame-ancestors 'self' is equivalent to SAMEORIGIN, while frame-ancestors 'none' blocks all framing. Both headers should be set for maximum browser compatibility.
Why This Matters for Vibe-Coded Apps
AI-generated applications typically do not set X-Frame-Options or CSP frame-ancestors headers, leaving them frameable by any website. While clickjacking is a lower-severity attack than XSS or SQL injection, it can be used to trick users into performing destructive actions like deleting data, changing settings, or granting permissions.
The fix is trivial: add X-Frame-Options: DENY to your response headers. This is a safe default for most applications — unless your app specifically needs to be embedded in iframes on other domains. Add this to your hosting platform's header configuration or your server's response headers as part of your security headers setup.
Real-World Examples
Facebook Likejacking (2010)
Attackers created pages with invisible Facebook Like buttons overlaid on enticing content. When users clicked "Play Video" or similar bait, they actually Liked a Facebook page, which then appeared in their friends' feeds, spreading the attack virally. Millions of users were affected before Facebook implemented frame-busting protections.
Twitter Follow Clickjacking
A clickjacking attack tricked Twitter users into following specific accounts by overlaying an invisible Follow button over engaging content. The attack was used to artificially inflate follower counts and could spread worm-like through retweet clickjacking, where users unknowingly retweeted malicious content.
Adobe Flash Webcam Hijacking
A clickjacking attack against Adobe Flash's settings manager tricked users into enabling their webcam and microphone by overlaying invisible permission dialogs over a game. Users thought they were clicking game buttons but were actually granting camera access to the attacker's page.
Frequently Asked Questions
What is the difference between X-Frame-Options and frame-ancestors?
X-Frame-Options is an older header with limited values: DENY, SAMEORIGIN, and ALLOW-FROM (deprecated). CSP frame-ancestors is the modern replacement, supporting multiple domains (frame-ancestors 'self' https://trusted.com), more flexible patterns, and is part of the broader CSP standard. Use both for maximum compatibility: X-Frame-Options for older browsers and frame-ancestors in your CSP for modern browsers.
Can JavaScript frame-busting prevent clickjacking?
JavaScript-based frame-busting (checking if window.top !== window.self) is unreliable. Attackers can prevent the script from running using the sandbox attribute on the iframe, which disables JavaScript in the framed content. The HTML5 sandbox attribute effectively bypasses all JavaScript-based frame-busting techniques. HTTP headers (X-Frame-Options and frame-ancestors) are enforced by the browser before any scripts execute and cannot be bypassed this way.
Does clickjacking work on mobile browsers?
Yes, but with differences. Mobile browsers support iframes, so the core attack vector exists. However, the smaller screen size makes precise overlay positioning harder. Touch events add complications — some mobile browsers handle overlapping touch targets differently. Tapjacking is the mobile-specific variant, exploiting Android's screen overlay permissions to place invisible elements over system permission dialogs.
When should I use SAMEORIGIN instead of DENY?
Use SAMEORIGIN when your application embeds its own pages in iframes, such as for modal dialogs, preview panes, or admin dashboards that frame other pages of your app. Use DENY when your pages should never be framed, which is the case for most pages. DENY is the safer default — only switch to SAMEORIGIN if you have a specific technical requirement for same-origin framing.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to clickjacking and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan