What Is Clickjacking and How Does It Work?
Author: Domeny.ForSale editorial team Published
In brief: Clickjacking, also called a UI redress attack, tricks users into clicking an element other than the one they see. An attacker might, for example, place an invisible page containing a button over an apparently harmless game button. Website owners limit these attacks primarily by controlling who can embed their pages, while users can help protect themselves by being cautious about suspicious interactions.
How click hijacking works
A browser can display one page inside another using an iframe element, or embedded frame. This is a normal feature used to display videos or maps, for example. In a clickjacking attack, the attacker uses it to hide the real target of a click beneath or above a specially designed interface.
A typical scenario works like this: a user opens a page controlled by the attacker, which loads another website in a frame. The frame is transparent or carefully cropped and positioned so that its button sits exactly where the user expects to click. The user sees one instruction, but the browser registers an interaction with a different element.
The attacker does not need to read the other site’s content. Browser restrictions on access between different websites do not necessarily prevent embedding pages or directing clicks to them. Protecting data from being read and preventing an interface from being embedded are therefore two separate tasks.
Example: a reward that triggers a different action
Imagine a page with a simple game and a “Claim your reward” button. Above that button is an invisible frame containing another service’s control panel. If that service allows embedding and the user’s session works within the frame, the click may land on a button that performs an operation on their account.
This does not mean that every visit to a malicious page immediately leads to an account takeover. Success depends on factors including the target website’s security measures, whether the logged-in session is available within the frame, and whether the operation requires additional confirmation. Cookie settings and browser restrictions can make this scenario harder to carry out, but they are not a substitute for protection against embedding.
Possible consequences include unintended changes to settings, actions performed within the service, or approval of an operation. Additional confirmation requiring deliberate user action reduces the risk, but another button alone does not guarantee protection: an attack may try to guide the victim through several clicks.
How clickjacking differs from phishing and CSRF
In phishing, a fraudster typically impersonates a trusted entity to steal information or persuade someone to take a particular action. With clickjacking, the user may instead click an element on a genuine service, but one hidden within a misleading interface. The two techniques can be used together, but their mechanisms differ.
CSRF, or cross-site request forgery, causes an unwanted request to be sent to a service using a logged-in user’s privileges without their informed consent. Clickjacking focuses on hijacking interactions with the interface. A CSRF protection token is not enough to prevent clickjacking, because the click may submit a legitimate form with its valid token.
HTTPS does not solve this problem either. It encrypts the connection to a website, but does not establish whether its interface is trustworthy or its owner has honest intentions.
How to protect your website
The primary protection is the HTTP response header Content-Security-Policy with the frame-ancestors directive. An HTTP header is information sent by the server to the browser along with the page. This directive specifies which origins may embed the page in frames.
If the website should never be embedded, you can use:
Content-Security-Policy: frame-ancestors 'none'
If embedding should be allowed only within the same origin—the same combination of protocol, host and port—the appropriate value is:
Content-Security-Policy: frame-ancestors 'self'
An older mechanism is X-Frame-Options with the value DENY or SAMEORIGIN. It can be used as a compatible fallback for older clients. The frame-ancestors directive offers more flexible control, such as allowing a specific partner origin. It must be sent as a response header: placing it in a meta tag will not provide this protection.
Implementation involves three steps:
- Identify which pages genuinely need to work within frames, for example as part of a partner integration.
- Set the appropriate policy on the server, in the application or through an intermediary service, and check the headers in your browser’s developer tools.
- Test both the blocking of unwanted embedding and the operation of legitimate integrations.
Do not rely solely on JavaScript scripts that attempt to break a page out of a frame. These approaches have limitations and can be bypassed. For sensitive operations, also require reauthentication or confirmation that clearly describes the action being performed.
What users can do
Avoid pages that require a series of unexplained clicks, especially under the pretext of claiming a reward, unlocking a video or completing supposed verification. Keep your browser up to date, but remember that the latest version cannot replace security measures on the service you are visiting.
If you suspect that a click triggered an unwanted action, navigate to the genuine service yourself rather than using a link on the suspicious page. Check your activity history and any changed settings, and report unauthorized operations to support. Website owners should start by checking the frame-ancestors header on account and administration pages.
See also: What Is Mass Assignment?
Read also
