Clickjacking (also called a UI redress attack) is a web security vulnerability where an attacker overlays an invisible iframe on a legitimate page, tricking users into clicking hidden elements that perform unintended actions like granting permissions, transferring funds, or exposing sensitive data. The term was coined by security researchers Jeremiah Grossman and Robert Hansen in 2008. For healthcare websites that handle electronic protected health information (ePHI), a successful clickjacking attack can trigger unauthorized disclosure of patient data, which is a violation of the HIPAA Security Rule’s Technical Safeguards under 45 CFR ยง164.312.
TL;DR: Quick Answer
An attacker creates a decoy webpage that looks harmless. On that page, they load your real website inside a transparent iframe positioned exactly over a button or link on the decoy. The user sees the decoy. When they click what appears to be a normal button, they are actually clicking an element on your site inside the invisible iframe.
The result can be anything the hidden element does: approving a transaction, granting a permission, changing account settings, or submitting a form. The user has no idea the real action happened.
This attack works because browsers normally allow any page to load any other page inside an iframe. The defenses described later in this article work by telling browsers to restrict that behavior.
This is the original form. An attacker overlays a transparent iframe on top of a legitimate page. The user thinks they are interacting with the visible content but is actually triggering an action on the hidden layer beneath it. This type was demonstrated in 2008 by Jeremiah Grossman and Robert Hansen using the Adobe Flash Player settings manager, which allowed attackers to silently enable a user’s microphone and camera.
Likejacking places a hidden Facebook Like button or other social media interaction element over a decoy page. The user clicks what appears to be a normal link and unknowingly likes content they have never seen. This attack was widely exploited from 2010 to 2011, including the 2009 Twitter “Don’t Click” worm, which OWASP documents as one of the earliest mass clickjacking incidents.
Cursorjacking moves the visual position of the cursor on screen so it appears to be somewhere it is not. The user believes they are clicking one element but their click registers on a different location entirely.
This variant tricks users into dragging content from one location to another. Because drag-and-drop events are handled differently than clicks in some browsers, they can be exploited to exfiltrate data or perform actions that click-based defenses do not cover.
Rather than completing an attack in a single click, multistep attacks guide users through several interactions before an unintended action completes. Each step looks harmless. The user only realizes something went wrong after the sequence is finished.
Gesturejacking and DoubleClickjacking are newer variants documented by security researcher Paulos Yibelo in December 2025. These attacks use CSS and SVG manipulation to hijack gesture-based interactions and double-click events. They can bypass traditional X-Frame-Options and CSP frame-ancestors defenses because they exploit the timing between two clicks or a gesture rather than a simple iframe overlay. This is an evolving attack type that demonstrates why defense-in-depth matters.
Filejacking tricks users into dragging files from their local system into an attacker-controlled area. Cookiejacking exploits drag-and-drop behavior to steal session cookies. Both are documented variants in OWASP and security research literature.
2008 Adobe Flash Settings Manager: The original demonstration by Grossman and Hansen showed that a transparent iframe over the Flash Player settings page could silently enable a user’s microphone and webcam. Adobe Flash reached end-of-life in December 2020, so this specific vector no longer applies. However, the same risk exists today with HTML5 browser permission prompts for microphone, camera, and location access. Attackers can overlay these prompts to get users to grant permissions they never intended to grant.
2009 Twitter “Don’t Click” Worm: A clickjacking attack spread across Twitter by tricking users into clicking a hidden “retweet” button. OWASP documents this as one of the first viral clickjacking exploits.
Facebook Likejacking (2010-2011): Attackers overlaid hidden Like buttons across thousands of websites. Users who thought they were clicking innocent links were actually liking content on Facebook. The incident led Facebook to implement frame-busting protections.
Banking and Payment Fraud: Clickjacking is used to trick users into authorizing transfers or changing account settings. The user sees a harmless confirmation page while the hidden iframe submits a financial action on a real banking site.
CAPTCHA Farming: Attackers use clickjacking to route CAPTCHA challenges to real users who solve them without knowing they are completing an authentication step for an automated bot. OWASP documents this as a legitimate attack pattern.
Healthcare websites are a specific target because the consequences of a successful attack go beyond annoyance or financial loss. A clickjacking attack on a patient portal or online intake form could cause a user to unknowingly submit or grant access to protected health information.
Under the HIPAA Security Rule, covered entities and business associates are required to implement technical safeguards that control access to ePHI (45 CFR ยง164.312). Missing security headers like CSP frame-ancestors and X-Frame-Options would be flagged as a vulnerability during a security risk analysis (45 CFR ยง164.308(a)(1)(ii)(A)). OCR has cited web application vulnerabilities in enforcement actions as evidence of failure to implement required technical safeguards.
This is also part of the shared responsibility model that applies to hosted environments. Your hosting provider is responsible for the server-level infrastructure. You and your provider are jointly responsible for ensuring that security headers are configured and maintained. HIPAA Compliant Hosting ships all managed AWS environments with CSP frame-ancestors, X-Frame-Options, and HSTS pre-configured, covering this layer of the HIPAA Security Rule without requiring your team to manage it manually.
If your hosting provider does not handle security headers as part of their managed service, a missing header is your liability. This is one of the reasons that signing a Business Associate Agreement (BAA) with a managed HIPAA hosting provider matters: the BAA establishes who is responsible for which parts of your security environment.
OWASP classifies missing security headers, including the absence of clickjacking protections, under A05:2021 Security Misconfiguration in the OWASP Top Ten. For any healthcare organization performing a HIPAA security risk analysis, this category should be on the checklist.
OWASP recommends implementing multiple defenses at the same time rather than relying on any single control. The following five methods should be used together.
The Content Security Policy frame-ancestors directive is the modern standard for clickjacking prevention. It tells the browser which origins are allowed to embed your page in an iframe, frame, or object. MDN, OWASP, and the W3C CSP Level 3 specification all state that CSP frame-ancestors is the replacement for X-Frame-Options.
To block all framing entirely:
Content-Security-Policy: frame-ancestors 'none';To allow your own domain only:
Content-Security-Policy: frame-ancestors 'self';To allow your domain and a specific trusted partner:
Content-Security-Policy: frame-ancestors 'self' https://trusted-partner.com;For Apache, add to your .htaccess or server config:
Header always set Content-Security-Policy "frame-ancestors 'none';"For Nginx:
add_header Content-Security-Policy "frame-ancestors 'none';" always;CSP frame-ancestors supports multiple allowed origins and is prioritized by all modern browsers over X-Frame-Options when both headers are present.
X-Frame-Options is an older HTTP header that serves as a fallback for browsers that do not support CSP frame-ancestors, primarily Internet Explorer and older legacy browsers. It should be implemented alongside CSP, not instead of it.
Valid options:
DENY: Blocks all framing of this page.SAMEORIGIN: Allows framing only from the same domain.For Apache:
Header always set X-Frame-Options "SAMEORIGIN"For Nginx:
add_header X-Frame-Options "SAMEORIGIN" always;Important: Do not use ALLOW-FROM. The ALLOW-FROM directive was never supported by Chrome or Edge, and it was removed from Firefox in version 70 (2019). MDN Web Docs marks it as deprecated. Any site relying on ALLOW-FROM for clickjacking protection has no protection in modern browsers. Use CSP frame-ancestors to specify allowed origins instead.
SameSite is a cookie attribute that tells the browser not to send a cookie when the request comes from a different origin. This directly addresses authenticated clickjacking, where the attack only works if the user is already logged into the target site.
Setting your session cookies to SameSite=Strict or SameSite=Lax means that even if a user is tricked into clicking a hidden iframe element, the request will not carry their session cookie. The hidden action will fail because the server sees it as an unauthenticated request.
Set-Cookie: sessionid=abc123; SameSite=Strict; Secure; HttpOnlySameSite=Strict blocks the cookie on all cross-origin requests. SameSite=Lax blocks it on most cross-origin requests but allows it for top-level navigation. For healthcare session management, Strict is the safer default.
SameSite cookie support is documented in RFC 6265bis and is supported in all modern browsers. OWASP’s current Clickjacking Defense Cheat Sheet lists SameSite cookies as one of the three main defenses alongside CSP and X-Frame-Options.
JavaScript frame-busting scripts check whether the page is loaded inside an iframe and redirect to the top-level page if it is.
javascript
if (window.top !== window.self) {
window.top.location = window.self.location;
}This provides a minimal layer of defense, but it is easily bypassed. Stanford researchers Rydstedt, Bursztein, Boneh, and Jackson documented multiple bypass techniques in 2010. The most common bypass uses the iframe sandbox attribute:
html
<iframe src="target.html" sandbox="allow-scripts allow-forms"></iframe>The sandbox attribute restricts what the framed page can do. When allow-top-navigation is omitted, the frame-busting script cannot redirect the top window, so it silently fails. Auth0 states: “client-side defenses to clickjacking attacks are easy to get around and are not recommended” as a sole defense.
Use JavaScript frame-busting only as an additional layer on top of CSP frame-ancestors and X-Frame-Options. Never rely on it alone.
Create a simple HTML file containing an iframe that points to your site. If your page loads inside the iframe, you have no clickjacking protection.
html
<html>
<body>
<iframe src="https://yoursite.com" width="800" height="600"></iframe>
</body>
</html>Open this file in a browser. If your site renders inside the frame, your headers are missing or misconfigured. If the browser blocks the iframe, your CSP frame-ancestors or X-Frame-Options header is working. OWASP’s Web Security Testing Guide (WSTG-CLNT-09) documents this testing approach.
Note on HTTPS: HTTPS protects data in transit from interception but has no effect on clickjacking. Clickjacking is a UI-layer attack that works identically on HTTPS and HTTP sites. Implementing HTTPS is essential for overall web security but does not substitute for the headers above.
Configuring and maintaining security headers is an ongoing task. Headers need to be set correctly across every server configuration, kept up to date as CSP specifications evolve, and verified after any hosting change or update.
HIPAA Compliant Hosting manages all AWS environments with CSP frame-ancestors, X-Frame-Options, and HSTS pre-configured as part of the baseline setup. Every plan includes a signed Business Associate Agreement (BAA) that covers the managed infrastructure. Your team does not need to write or maintain these headers manually.
For healthcare practices, telehealth platforms, and EHR vendors that store or transmit ePHI, this removes one documented category of HIPAA Security Rule risk from your plate. The security header configuration is part of the technical safeguards layer that HIPAA Compliant Hosting handles under the shared responsibility model.
Clickjacking is a cyberattack where an attacker overlays a transparent iframe on a legitimate page, tricking users into clicking hidden elements that perform unintended actions. It is also known as a UI redress attack. The term was coined by Jeremiah Grossman and Robert Hansen in 2008.
The attacker loads a target website inside a transparent iframe and positions it over a decoy page. When the user clicks what appears to be a harmless button on the decoy, they are actually clicking an element on the hidden target page inside the iframe.
Use CSP frame-ancestors as the primary defense, X-Frame-Options as a legacy fallback for older browsers, and SameSite cookie attributes to prevent authenticated clickjacking. OWASP recommends implementing all three together as defense-in-depth.
CSP frame-ancestors is the modern replacement for X-Frame-Options. It supports multiple allowed origins, is part of the W3C CSP Level 3 standard, and is given priority by all modern browsers when both headers are present. X-Frame-Options is a legacy header maintained for compatibility with older browsers like Internet Explorer.
No. ALLOW-FROM was never supported by Chrome or Edge and was removed from Firefox in version 70 (2019). MDN Web Docs marks it as deprecated. Any site relying on ALLOW-FROM has no clickjacking protection in modern browsers. Use CSP frame-ancestors to specify allowed embedding origins instead.
JavaScript frame-busting scripts provide a minimal legacy defense but are easily bypassed using the iframe sandbox attribute. Server-side HTTP headers, specifically CSP frame-ancestors, are the recommended primary defense. JavaScript frame-busting should only be used as an additional layer, never as the sole control.
No. HTTPS protects data in transit but has no effect on clickjacking attacks. Clickjacking is a UI-layer attack that works identically on HTTPS and HTTP sites. Prevention requires CSP frame-ancestors or X-Frame-Options headers, not transport-layer encryption.
Likejacking is a form of clickjacking that tricks users into clicking a hidden Facebook Like or social media interaction button. The user thinks they are clicking a normal link but are actually interacting with a hidden social media element. It was widely exploited in 2010 and 2011 and is documented by OWASP.
Yes. Healthcare websites handling ePHI are particularly vulnerable because a successful clickjacking attack could lead to unauthorized disclosure of protected health information, which is a HIPAA Security Rule violation under 45 CFR ยง164.312. Missing clickjacking protections would be flagged in a HIPAA security risk analysis.
Create an HTML file with an iframe that loads your website. If your site renders inside the iframe, your clickjacking protections are missing. OWASP documents this testing approach in their Web Security Testing Guide (WSTG-CLNT-09). If you use HIPAA Compliant Hosting, clickjacking header protections are pre-configured as part of your managed environment.
Technical standards referenced: OWASP Clickjacking Defense Cheat Sheet; MDN Web Docs (X-Frame-Options, CSP frame-ancestors); W3C Content Security Policy Level 3; RFC 7034 (HTTP Header Field X-Frame-Options); RFC 6265bis (SameSite cookies); OWASP Top Ten A05:2021 Security Misconfiguration; OWASP Web Security Testing Guide WSTG-CLNT-09; Stanford frame-busting research, Rydstedt et al. (2010); Paulos Yibelo, Gesturejacking/DoubleClickjacking (December 2025). HIPAA regulatory references: 45 CFR ยง164.312 (Technical Safeguards), 45 CFR ยง164.308(a)(1)(ii)(A) (Security Risk Analysis).
