Clickjacking

Clickjacking is a type of attack where the attacker sets up a page so that a user’s click on the page performs a different action than the one the user intends. It gets its name because the attacker has “hijacked a click”. OWASP describes it as a UI-redress attack: “an attacker uses multiple transparent or opaque layers to trick a user into clicking on a button or link on another page when they were intending to click on the top level page.”

The typical setup is that the attacker hosts a malicious page and embeds the legitimate target site inside an invisible <iframe>. The attacker layers the framed page on top of (or under) decoy content so that a user who thinks they are clicking on the attacker’s page is actually clicking on a button inside the framed target site. This does not require Cross-Site Scripting on the target — the target page can be perfectly secure and still be framed by another origin. (XSS can amplify a clickjacking attack when the target site is also vulnerable to script injection, but it is not a prerequisite.)

The simplest version is to put an invisible link over a regular link. Imagine a web page with an embedded video. The user clicks on the video’s “play” button. But the click does not start the video, it never gets to the video player. Instead the user has just clicked on a hidden link on a transparent overlay over the page. Most of the time the user will not even know they have triggered the link because it targets a hidden iframe. The results of the linked page will be hidden from view. The user will simply think the link didn’t work on the first click.

The link could trigger many actions. Some common ones are:

Voting for an online poll
Playing video content to increase views
Showing an advertisement (ad revenue)
Following someone on social media
Sharing or liking on social media
Enabling a web cam or microphone
Viewing an imitation HTML page
Downloading malware
Disabling security settings

Cursorjacking

Cursorjacking is a variation on clickjacking. Instead of “intercepting” a click, the attacker alters the cursor’s actual location from the location the user perceives. For example, a click might register 100 pixels to the left of where the cursor appears to be.

As an example of how this could be useful, imagine a dialog box that pops up with a choice for the user to make: “Enable web cam” and “Cancel”. A user thinks the cursor is over “Cancel” and clicks, but the click registers on the “Enable web cam” button.

Clickjacking Preventions

The OWASP Clickjacking Defense Cheat Sheet recommends a defense-in-depth approach: combine framing controls with cookie protections so that, even if a page is framed, the framed request does not carry the victim’s authenticated session.

Define a Content Security Policy and set the frame-ancestors directive to disallow loading the page inside a frame or iframe. If a page must be framed, allow only specific origins. frame-ancestors is the modern replacement for X-Frame-Options and offers more granular control (multiple allowed origins, wildcard hosts).
Configure the webserver (or your application code) to set the X-Frame-Options response header to DENY or SAMEORIGIN. This header still works in current browsers and is useful as a fallback alongside CSP. Note that the older ALLOW-FROM origin value is obsolete and ignored by modern browsers — use CSP frame-ancestors if you need to allow specific origins.
Set authentication cookies with SameSite=Lax or SameSite=Strict (and the Secure flag) so that the browser does not send session cookies on requests issued by a cross-site frame. This prevents the framed request from being treated as an authenticated action even if the framing controls fail.

In addition, users can take precautions of their own. They can install browser extensions, such as NoScript, which disable or reveal unexpected JavaScript.