Fix Clickjacking Vulnerabilities

A clickjacking attack works by placing your legitimate website in a transparent iframe positioned precisely over a decoy page. The attacker uses CSS opacity: 0 and z-index manipulation to make your site invisible to the user while still interactive. When the victim clicks what appears to be an innocent button on the decoy page — a prize claim, a video play button, a survey — they are actually clicking a button on your hidden site. The attacker controls the positioning to align your most dangerous actions (confirm payment, grant permission, delete account) with the decoy's clickable area. On mobile devices, the same technique works with touch events and swipe gestures.

Clickjacking vulnerabilities are entirely preventable with two HTTP headers. The older protection is X-Frame-Options, introduced in 2009 and supported by every browser. Setting it to DENY prevents your page from being framed by any origin; SAMEORIGIN allows framing only by pages on the same domain. X-Frame-Options has no wildcard or specific-domain allowlist capability — if you need to allow framing by specific trusted third-party domains, you must use the Content-Security-Policy header instead. The frame-ancestors directive in CSP allows precise control: frame-ancestors 'none' (equivalent to DENY) or frame-ancestors 'self' (equivalent to SAMEORIGIN) or frame-ancestors https://trusted-partner.com 'self' for a specific allowlist.

CSP frame-ancestors is the modern, preferred protection because it supports multiple allowed origins and is not vulnerable to a subtle limitation of X-Frame-Options: in some older browser implementations, X-Frame-Options headers sent in meta tags or by intermediary proxies were not consistently honoured. A Content-Security-Policy header with frame-ancestors issued from the origin server is processed by all modern browsers before any framing is attempted. If both headers are present, browsers that support CSP will use frame-ancestors and ignore X-Frame-Options. For maximum compatibility with older browsers, it is best practice to set both headers simultaneously.

Not every page on your application requires the same clickjacking protection level. Static marketing pages with no user actions might be acceptable to frame — embedding a product demo in a partner's page is a legitimate business case. The pages that absolutely must be protected are those that perform state-changing actions: login forms, password reset flows, payment confirmation pages, settings pages, and any OAuth authorisation endpoint. A clickjacking vulnerability on a payment confirmation page combined with a well-crafted decoy page can cause users to authorise financial transactions without any awareness. Vuln0x's scanner tests the pages that a crawler discovers during the scan, and the full scan report lists each URL and its frame-protection status individually.

Beyond HTTP headers, some teams implement a JavaScript frame-buster as an additional layer, although this should never be the primary defence. Frame-busters — scripts that detect when the page is loaded inside an iframe and break out or redirect — can be defeated by an attacker who uses the HTML5 sandbox attribute on the iframe element (sandbox prevents JavaScript execution in the framed content). Headers, by contrast, are enforced by the browser before the page renders and cannot be bypassed by the attacker's page. Vuln0x's clickjacking report provides environment-specific remediation examples: nginx add_header directives, Apache Header set lines, Next.js middleware configuration, Express.js helmet settings, and Django SecurityMiddleware configuration — so you can apply the fix in your specific stack without additional research.